Re: [RFCv3,3/3] soc_camera: initial of code

2014-04-01 Thread Josh Wu 

Hi, Ben

On 3/31/2014 6:10 PM, Ben Dooks wrote:

On 31/03/14 10:28, Josh Wu wrote:

Hi, Ben

Thanks for the patch, I just test atmel-isi with the your patch,
I find the mclk registered in soc-camera driver cannot be find
by the soc-camera sensors. See comment in below:


Ok, I guess that the driver I have does not need the
mclk clock.




... ...



+#ifdef CONFIG_OF
+static int soc_of_bind(struct soc_camera_host *ici,
+   struct device_node *ep,
+   struct device_node *remote)
+{
+struct soc_camera_device *icd;
+struct soc_camera_desc sdesc = {.host_desc.bus_id = ici-nr,};
+struct soc_camera_async_client *sasc;
+struct soc_camera_async_subdev *sasd;
+struct v4l2_async_subdev **asd_array;
+char clk_name[V4L2_SUBDEV_NAME_SIZE];
+int ret;
+
+/* alloacte a new subdev and add match info to it */
+sasd = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sasd), GFP_KERNEL);
+if (!sasd)
+return -ENOMEM;
+
+asd_array = devm_kzalloc(ici-v4l2_dev.dev,
+ sizeof(struct v4l2_async_subdev **),
+ GFP_KERNEL);
+if (!asd_array)
+return -ENOMEM;
+
+sasd-asd.match.of.node = remote;
+sasd-asd.match_type = V4L2_ASYNC_MATCH_OF;
+asd_array[0] = sasd-asd;
+
+/* Or shall this be managed by the soc-camera device? */
+sasc = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sasc), GFP_KERNEL);
+if (!sasc)
+return -ENOMEM;
+
+/* HACK: just need a != NULL */
+sdesc.host_desc.board_info = ERR_PTR(-ENODATA);
+
+ret = soc_camera_dyn_pdev(sdesc, sasc);
+if (ret  0)
+return ret;
+
+sasc-sensor = sasd-asd;
+
+icd = soc_camera_add_pdev(sasc);
+if (!icd) {
+platform_device_put(sasc-pdev);
+return -ENOMEM;
+}
+
+//sasc-notifier.subdevs = asd;
+sasc-notifier.subdevs = asd_array;
+sasc-notifier.num_subdevs = 1;
+sasc-notifier.bound = soc_camera_async_bound;
+sasc-notifier.unbind = soc_camera_async_unbind;
+sasc-notifier.complete = soc_camera_async_complete;
+
+icd-sasc = sasc;
+icd-parent = ici-v4l2_dev.dev;
+
+snprintf(clk_name, sizeof(clk_name), of-%s,
+ of_node_full_name(remote));


The clk_name you register here is a OF string, but for the i2c 
sensors, which
call the v4l2_clk_get by using dev_name(client-dev). It is format 
like:

1-0030, combined i2c adaptor ID and addr.
So the i2c sensor can not find this registered mclk as the name is 
not match.


Hmm, this sounds like something that really should go
away and be handled by the clk system instead.


Since the v4l2 clk (mclk) is just a temperory solution and it will be 
removed if all use common clk framework.

(See the commit message of ff5430de70).

So IMHO we can live with this, just simply add the code in soc_of_bind():

+   struct i2c_client *client;
... ...

 client = of_find_i2c_device_by_node(remote);
+   if (!client)
+   goto eclkreg;

-snprintf(clk_name, sizeof(clk_name), of-%s,
-   of_node_full_name(remote));
+   snprintf(clk_name, sizeof(clk_name), %d-%04x,
+client-adapter-nr, client-addr);

icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, 
mclk, icd);




[snip]



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

Re: [PATCH 1/2] media: davinci: vpif capture: upgrade the driver with v4l offerings

2014-04-01 Thread Hans Verkuil 
On 03/31/2014 07:24 PM, Prabhakar Lad wrote:
 Hi Hans,
 
 On Mon, Mar 31, 2014 at 8:34 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi Prabhakar,

 This looks really nice!

 Writing a video driver has become really easy with almost 90% of work
 done by v4l core itself :)

That was the idea!

 I'll do a full review on Friday, but in the meantime can you post the output
 OK.
 
 of 'v4l2-compliance -s' using the latest v4l2-compliance version? I've made
 some commits today, so you need to do a git pull of v4l-utils.git.

 I had compilation failures for v4l2-compliance following is the patch
 fixing that, (I am
 facing some issues in cross compilation once done I'll post the o/p of it)

I fixed the 'friend' issue (weird that it didn't fail with my g++) and the other
issue was already fixed yesterday.

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] Fix _IOC_TYPECHECK sparse error

2014-04-01 Thread Hans Verkuil 
When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these
errors:

drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant 
expression
drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant 
expression
drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant 
expression
drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant 
expression

etc.

The root cause of that turns out to be in include/asm-generic/ioctl.h:

#include uapi/asm-generic/ioctl.h

/* provoke compile error for invalid uses of size argument */
extern unsigned int __invalid_size_argument_for_IOC;
#define _IOC_TYPECHECK(t) \
((sizeof(t) == sizeof(t[1])  \
  sizeof(t)  (1  _IOC_SIZEBITS)) ? \
  sizeof(t) : __invalid_size_argument_for_IOC)

If it is defined as this (as is already done if __KERNEL__ is not defined):

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

then all is well with the world.

This patch allows sparse to work correctly.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com

diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h
index d17295b..297fb0d 100644
--- a/include/asm-generic/ioctl.h
+++ b/include/asm-generic/ioctl.h
@@ -3,10 +3,15 @@
 
 #include uapi/asm-generic/ioctl.h
 
+#ifdef __CHECKER__
+#define _IOC_TYPECHECK(t) (sizeof(t))
+#else
 /* provoke compile error for invalid uses of size argument */
 extern unsigned int __invalid_size_argument_for_IOC;
 #define _IOC_TYPECHECK(t) \
((sizeof(t) == sizeof(t[1])  \
  sizeof(t)  (1  _IOC_SIZEBITS)) ? \
  sizeof(t) : __invalid_size_argument_for_IOC)
+#endif
+
 #endif /* _ASM_GENERIC_IOCTL_H */

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

Re: Writing a HDMI-CEC device driver for the IT66121

2014-04-01 Thread Hans Verkuil 
Hi Sri,

On 03/31/14 23:12, Sriakhil Gogineni wrote:
 Hi,
 
 I'm trying to write a HDMI-CEC driver for the Radxa Rock
 (Specification - Radxa). I am coming from a software background and
 have found libcec and am looking at other implementation.
 
 I'm wondering how to connect the hardware and software pieces under
 Linux / Android.
 
 I'm not sure if I need to find out what /dev/ its exposed under via
 the device tree or determine which register is used from the data
 sheet?
 
 Any advice / tips / pointers would be helpful.

There is currently no kernel CEC support available. What makes cec
complex is 1) the CEC specification is horrible :-) and 2) a proper cec
implementation has to be able to take care of v4l2 devices, drm/kms devices
and usb dongles. In addition, at least some of the CEC handling has to
take place in the kernel in order to handle the audio return channel,
suspend commands, hotplug-over-CEC and such advanced features.

I have been working on this, but it is a background project and I never
found the time to finish it.

My latest code is available here:

http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cec

but it needs more work to make this ready for prime time.

It works, but it needs cleanup and cec_claim_log_addrs() needs improvement.
Particularly when called from a driver: this needs to be done in non-
blocking mode which isn't yet working (in blocking mode the driver would
block for an unacceptable amount of time).

If you or someone else would be willing to take over, I would have no
objections. I have no idea when I might have time to continue work on
this.

Regards,

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

Re: [PATCH v3] vb2: Check if there are buffers before streamon

2014-04-01 Thread Andrzej Hajda 
Hi,

It seems the patch has been applied twice in linux-next/master:

$ git log --oneline -25 linux-next/master
drivers/media/v4l2-core/videobuf2-core.c
9cf3c31 [media] vb2: call buf_finish after the state check
3f1a9a3 [media] vb2: fix streamoff handling if streamon wasn't called
e4d2581 [media] vb2: replace BUG by WARN_ON
fb64dca [media] vb2: properly clean up PREPARED and QUEUED buffers
b3379c6 [media] vb2: only call start_streaming if sufficient buffers are
queued
a7afcac [media] vb2: don't init the list if there are still buffers
6ea3b98 [media] vb2: rename queued_count to owned_by_drv_count
256f316 [media] vb2: fix buf_init/buf_cleanup call sequences
9c0863b [media] vb2: call buf_finish from __queue_cancel
0647064 [media] vb2: change result code of buf_finish to void
b5b4541 [media] vb2: add debugging code to check for unbalanced ops
952c9ee [media] vb2: fix PREPARE_BUF regression
4e5a4d8 [media] vb2: fix read/write regression
 249f5a5 [media] vb2: Check if there are buffers before streamon
c897df0 Merge tag 'v3.14-rc5' into patchwork
7ce6fd8 [media] v4l: Handle buffer timestamp flags correctly
872484c [media] v4l: Add timestamp source flags, mask and document them
c57ff79 [media] v4l: Timestamp flags will soon contain timestamp source,
not just type
ade4868 [media] v4l: Rename vb2_queue.timestamp_type as timestamp_flags
f134328 [media] vb2: fix timecode and flags handling for output buffers
 548df78 [media] vb2: Check if there are buffers before streamon



Regards
Andrzej

On 01/08/2014 09:01 AM, Ricardo Ribalda Delgado wrote:
 This patch adds a test preventing streamon() if there is no buffer
 ready.
 
 Without this patch, a user could call streamon() before
 preparing any buffer. This leads to a situation where if he calls
 close() before calling streamoff() the device is kept streaming.
 
 Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
 ---
 v2: Comment by Marek Szyprowski:
 Reword error message
 
 v3: Comment by Marek Szyprowski:
 Actualy do the reword :)
 
  drivers/media/v4l2-core/videobuf2-core.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
 b/drivers/media/v4l2-core/videobuf2-core.c
 index 098df28..6409e0a 100644
 --- a/drivers/media/v4l2-core/videobuf2-core.c
 +++ b/drivers/media/v4l2-core/videobuf2-core.c
 @@ -1776,6 +1776,11 @@ static int vb2_internal_streamon(struct vb2_queue *q, 
 enum v4l2_buf_type type)
   return 0;
   }
  
 + if (!q-num_buffers) {
 + dprintk(1, streamon: no buffers have been allocated\n);
 + return -EINVAL;
 + }
 +
   /*
* If any buffers were queued before streamon,
* we can now pass them to driver for processing.
 

--
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: [RFCv3,3/3] soc_camera: initial of code

2014-04-01 Thread Ben Dooks 

On 01/04/14 07:39, Josh Wu wrote:

Hi, Ben

On 3/31/2014 6:10 PM, Ben Dooks wrote:

On 31/03/14 10:28, Josh Wu wrote:

Hi, Ben

Thanks for the patch, I just test atmel-isi with the your patch,
I find the mclk registered in soc-camera driver cannot be find
by the soc-camera sensors. See comment in below:


Ok, I guess that the driver I have does not need the
mclk clock.




... ...



+#ifdef CONFIG_OF
+static int soc_of_bind(struct soc_camera_host *ici,
+   struct device_node *ep,
+   struct device_node *remote)
+{
+struct soc_camera_device *icd;
+struct soc_camera_desc sdesc = {.host_desc.bus_id = ici-nr,};
+struct soc_camera_async_client *sasc;
+struct soc_camera_async_subdev *sasd;
+struct v4l2_async_subdev **asd_array;
+char clk_name[V4L2_SUBDEV_NAME_SIZE];
+int ret;
+
+/* alloacte a new subdev and add match info to it */
+sasd = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sasd), GFP_KERNEL);
+if (!sasd)
+return -ENOMEM;
+
+asd_array = devm_kzalloc(ici-v4l2_dev.dev,
+ sizeof(struct v4l2_async_subdev **),
+ GFP_KERNEL);
+if (!asd_array)
+return -ENOMEM;
+
+sasd-asd.match.of.node = remote;
+sasd-asd.match_type = V4L2_ASYNC_MATCH_OF;
+asd_array[0] = sasd-asd;
+
+/* Or shall this be managed by the soc-camera device? */
+sasc = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sasc), GFP_KERNEL);
+if (!sasc)
+return -ENOMEM;
+
+/* HACK: just need a != NULL */
+sdesc.host_desc.board_info = ERR_PTR(-ENODATA);
+
+ret = soc_camera_dyn_pdev(sdesc, sasc);
+if (ret  0)
+return ret;
+
+sasc-sensor = sasd-asd;
+
+icd = soc_camera_add_pdev(sasc);
+if (!icd) {
+platform_device_put(sasc-pdev);
+return -ENOMEM;
+}
+
+//sasc-notifier.subdevs = asd;
+sasc-notifier.subdevs = asd_array;
+sasc-notifier.num_subdevs = 1;
+sasc-notifier.bound = soc_camera_async_bound;
+sasc-notifier.unbind = soc_camera_async_unbind;
+sasc-notifier.complete = soc_camera_async_complete;
+
+icd-sasc = sasc;
+icd-parent = ici-v4l2_dev.dev;
+
+snprintf(clk_name, sizeof(clk_name), of-%s,
+ of_node_full_name(remote));


The clk_name you register here is a OF string, but for the i2c
sensors, which
call the v4l2_clk_get by using dev_name(client-dev). It is format
like:
1-0030, combined i2c adaptor ID and addr.
So the i2c sensor can not find this registered mclk as the name is
not match.


Hmm, this sounds like something that really should go
away and be handled by the clk system instead.


Since the v4l2 clk (mclk) is just a temperory solution and it will be
removed if all use common clk framework.
(See the commit message of ff5430de70).

So IMHO we can live with this, just simply add the code in soc_of_bind():

+   struct i2c_client *client;
... ...

  client = of_find_i2c_device_by_node(remote);
+   if (!client)
+   goto eclkreg;

-snprintf(clk_name, sizeof(clk_name), of-%s,
-   of_node_full_name(remote));
+   snprintf(clk_name, sizeof(clk_name), %d-%04x,
+client-adapter-nr, client-addr);

 icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name,
mclk, icd);



[snip]


Thanks, I will look into this.

--
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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] v4l2-compliance: fix function pointer prototype

2014-04-01 Thread Lad, Prabhakar 
From: Lad, Prabhakar prabhakar.cse...@gmail.com

There was a conflict between the mmap function pointer prototype of
struct v4l_fd and the actual function used. Make sure it is in sync
with the prototype of v4l2_mmap.

This patch fixes following build error,

v4l2-compliance.cpp: In function 'void v4l_fd_test_init(v4l_fd*, int)':
v4l2-compliance.cpp:132: error: invalid conversion from
'void* (*)(void*, size_t, int, int, int, int64_t)' to
'void* (*)(void*, size_t, int, int, int, off_t)'

Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
 utils/v4l2-compliance/v4l-helpers.h |2 +-
 utils/v4l2-compliance/v4l2-compliance.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/v4l2-compliance/v4l-helpers.h 
b/utils/v4l2-compliance/v4l-helpers.h
index 48ea602..b2ce6c0 100644
--- a/utils/v4l2-compliance/v4l-helpers.h
+++ b/utils/v4l2-compliance/v4l-helpers.h
@@ -10,7 +10,7 @@ struct v4l_fd {
int fd;
int (*ioctl)(int fd, unsigned long cmd, ...);
void *(*mmap)(void *addr, size_t length, int prot, int flags,
- int fd, int64_t offset);
+ int fd, off_t offset);
int (*munmap)(void *addr, size_t length);
 };
 
diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
b/utils/v4l2-compliance/v4l2-compliance.h
index f2f7072..b6d4dae 100644
--- a/utils/v4l2-compliance/v4l2-compliance.h
+++ b/utils/v4l2-compliance/v4l2-compliance.h
@@ -137,7 +137,7 @@ static inline int test_ioctl(int fd, unsigned long cmd, ...)
 }
 
 static inline void *test_mmap(void *start, size_t length, int prot, int flags,
-   int fd, int64_t offset)
+   int fd, off_t offset)
 {
return wrapper ? v4l2_mmap(start, length, prot, flags, fd, offset) :
mmap(start, length, prot, flags, fd, offset);
-- 
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 v3] saa7134: add vidioc_querystd

2014-04-01 Thread Mikhail Domrachev 
Signed-off-by: Mikhail Domrachev mihail.domryc...@comexp.ru
---
 drivers/media/pci/saa7134/saa7134-empress.c |  1 +
 drivers/media/pci/saa7134/saa7134-reg.h |  5 
 drivers/media/pci/saa7134/saa7134-video.c   | 41 +++--
 drivers/media/pci/saa7134/saa7134.h |  1 +
 4 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/saa7134/saa7134-empress.c 
b/drivers/media/pci/saa7134/saa7134-empress.c
index 0a9047e..a150deb 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -262,6 +262,7 @@ static const struct v4l2_ioctl_ops ts_ioctl_ops = {
.vidioc_s_input = saa7134_s_input,
.vidioc_s_std   = saa7134_s_std,
.vidioc_g_std   = saa7134_g_std,
+   .vidioc_querystd= saa7134_querystd,
.vidioc_log_status  = v4l2_ctrl_log_status,
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event   = v4l2_event_unsubscribe,
diff --git a/drivers/media/pci/saa7134/saa7134-reg.h 
b/drivers/media/pci/saa7134/saa7134-reg.h
index e7e0af1..51737b1 100644
--- a/drivers/media/pci/saa7134/saa7134-reg.h
+++ b/drivers/media/pci/saa7134/saa7134-reg.h
@@ -167,17 +167,22 @@
 #define SAA7134_HSYNC_START 0x106
 #define SAA7134_HSYNC_STOP  0x107
 #define SAA7134_SYNC_CTRL   0x108
+#define   SAA7134_SYNC_CTRL_AUFD(1  7)
 #define SAA7134_LUMA_CTRL   0x109
+#define   SAA7134_LUMA_CTRL_LDEL(1  5)
 #define SAA7134_DEC_LUMA_BRIGHT 0x10a
 #define SAA7134_DEC_LUMA_CONTRAST   0x10b
 #define SAA7134_DEC_CHROMA_SATURATION   0x10c
 #define SAA7134_DEC_CHROMA_HUE  0x10d
 #define SAA7134_CHROMA_CTRL10x10e
+#define   SAA7134_CHROMA_CTRL1_AUTO0(1  1)
+#define   SAA7134_CHROMA_CTRL1_FCTC (1  2)
 #define SAA7134_CHROMA_GAIN 0x10f
 #define SAA7134_CHROMA_CTRL20x110
 #define SAA7134_MODE_DELAY_CTRL 0x111
 
 #define SAA7134_ANALOG_ADC  0x114
+#define   SAA7134_ANALOG_ADC_AUTO1  (1  2)
 #define SAA7134_VGATE_START 0x115
 #define SAA7134_VGATE_STOP  0x116
 #define SAA7134_MISC_VGATE_MSB  0x117
diff --git a/drivers/media/pci/saa7134/saa7134-video.c 
b/drivers/media/pci/saa7134/saa7134-video.c
index eb472b5..5eb61ca 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -452,19 +452,26 @@ static void video_mux(struct saa7134_dev *dev, int input)
 
 static void saa7134_set_decoder(struct saa7134_dev *dev)
 {
-   int luma_control, sync_control, mux;
+   int luma_control, sync_control, chroma_ctrl1, mux;
 
struct saa7134_tvnorm *norm = dev-tvnorm;
mux = card_in(dev, dev-ctl_input).vmux;
 
luma_control = norm-luma_control;
sync_control = norm-sync_control;
+   chroma_ctrl1 = norm-chroma_ctrl1;
 
if (mux  5)
luma_control |= 0x80; /* svideo */
if (noninterlaced || dev-nosignal)
sync_control |= 0x20;
 
+   /* switch on auto standard detection */
+   sync_control |= SAA7134_SYNC_CTRL_AUFD;
+   chroma_ctrl1 |= SAA7134_CHROMA_CTRL1_AUTO0;
+   chroma_ctrl1 = ~SAA7134_CHROMA_CTRL1_FCTC;
+   luma_control = ~SAA7134_LUMA_CTRL_LDEL;
+
/* setup video decoder */
saa_writeb(SAA7134_INCR_DELAY,0x08);
saa_writeb(SAA7134_ANALOG_IN_CTRL1,   0xc0 | mux);
@@ -487,7 +494,7 @@ static void saa7134_set_decoder(struct saa7134_dev *dev)
dev-ctl_invert ? -dev-ctl_saturation : dev-ctl_saturation);
 
saa_writeb(SAA7134_DEC_CHROMA_HUE,dev-ctl_hue);
-   saa_writeb(SAA7134_CHROMA_CTRL1,  norm-chroma_ctrl1);
+   saa_writeb(SAA7134_CHROMA_CTRL1,  chroma_ctrl1);
saa_writeb(SAA7134_CHROMA_GAIN,   norm-chroma_gain);
 
saa_writeb(SAA7134_CHROMA_CTRL2,  norm-chroma_ctrl2);
@@ -1686,6 +1693,35 @@ int saa7134_g_std(struct file *file, void *priv, 
v4l2_std_id *id)
 }
 EXPORT_SYMBOL_GPL(saa7134_g_std);
 
+static v4l2_std_id saa7134_read_std(struct saa7134_dev *dev)
+{
+   static v4l2_std_id stds[] = {
+   V4L2_STD_UNKNOWN,
+   V4L2_STD_NTSC,
+   V4L2_STD_PAL,
+   V4L2_STD_SECAM };
+
+   v4l2_std_id result = 0;
+
+   u8 st1 = saa_readb(SAA7134_STATUS_VIDEO1);
+   u8 st2 = saa_readb(SAA7134_STATUS_VIDEO2);
+
+   if (!(st2  0x1)) /* RDCAP == 0 */
+   result = V4L2_STD_UNKNOWN;
+   else
+   result = stds[st1  0x03];
+
+   return result;
+}
+
+int saa7134_querystd(struct file *file, void *priv, v4l2_std_id *std)
+{
+

Re: [PATCH] v4l2-compliance: fix function pointer prototype

2014-04-01 Thread Hans Verkuil 
Hi Prabhakar,

On 04/01/14 15:45, Lad, Prabhakar wrote:
 From: Lad, Prabhakar prabhakar.cse...@gmail.com
 
 There was a conflict between the mmap function pointer prototype of
 struct v4l_fd and the actual function used. Make sure it is in sync
 with the prototype of v4l2_mmap.

The prototype of v4l2_mmap uses int64_t, so I don't understand this
patch.

Regards,

Hans

 
 This patch fixes following build error,
 
 v4l2-compliance.cpp: In function 'void v4l_fd_test_init(v4l_fd*, int)':
 v4l2-compliance.cpp:132: error: invalid conversion from
 'void* (*)(void*, size_t, int, int, int, int64_t)' to
 'void* (*)(void*, size_t, int, int, int, off_t)'
 
 Cc: Hans Verkuil hans.verk...@cisco.com
 Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
 ---
  utils/v4l2-compliance/v4l-helpers.h |2 +-
  utils/v4l2-compliance/v4l2-compliance.h |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/utils/v4l2-compliance/v4l-helpers.h 
 b/utils/v4l2-compliance/v4l-helpers.h
 index 48ea602..b2ce6c0 100644
 --- a/utils/v4l2-compliance/v4l-helpers.h
 +++ b/utils/v4l2-compliance/v4l-helpers.h
 @@ -10,7 +10,7 @@ struct v4l_fd {
   int fd;
   int (*ioctl)(int fd, unsigned long cmd, ...);
   void *(*mmap)(void *addr, size_t length, int prot, int flags,
 -   int fd, int64_t offset);
 +   int fd, off_t offset);
   int (*munmap)(void *addr, size_t length);
  };
  
 diff --git a/utils/v4l2-compliance/v4l2-compliance.h 
 b/utils/v4l2-compliance/v4l2-compliance.h
 index f2f7072..b6d4dae 100644
 --- a/utils/v4l2-compliance/v4l2-compliance.h
 +++ b/utils/v4l2-compliance/v4l2-compliance.h
 @@ -137,7 +137,7 @@ static inline int test_ioctl(int fd, unsigned long cmd, 
 ...)
  }
  
  static inline void *test_mmap(void *start, size_t length, int prot, int 
 flags,
 - int fd, int64_t offset)
 + int fd, off_t offset)
  {
   return wrapper ? v4l2_mmap(start, length, prot, flags, fd, offset) :
   mmap(start, length, prot, flags, fd, offset);
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] uvcvideo: Fix clock param realtime setting

2014-04-01 Thread Laurent Pinchart 
Hi Olivier,

On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote:
 Hi Laurent,
 
   Yes. ffmpeg uses wall clock time to create timestamps for audio packets
   from ALSA device.
  
  OK. I suppose I shouldn't drop support for the realtime clock like I
  wanted to then :-)
  
   There is a bug in ffmpeg describing problems to synchronize audio and
   the video from a v4l2 webcam.
   
   https://trac.ffmpeg.org/ticket/692
   
   To workaround this issue, ffmpeg devs added a switch to convert back
   
   monotonic to realtime. From ffmpeg/libavdevice/v4l2.c:
 -tsint.D set type of timestamps for
grabbed frames (from 0 to 2)
(default 0)
default  .D use timestamps from the kernel
abs  .D use absolute timestamps (wall
clock)
mono2abs .D force conversion from monotonic
to absolute timestamps
   
   If the v4l2 driver is able to send realtime ts, it is easier synchronize
   in userspace if all inputs use the same clock.
  
  That might be a stupid question, but shouldn't ALSA use the monotonic
  clock instead ?
 
 I think that I have that answer why ffmpeg use realtime clock for ALSA data.
 In fact ffmpeg uses realtime clock for every data coming from capture
 devices and the purpose is to be able to seek into the recorded stream by
 using the date where the recording occured. Same principle than a camera
 recording dates when pictures are taken.

 now a tougher question is whether or not it is up to the driver to provide
 these realtime ts.

It makes sense to associate a wall time with recorded streams for that 
purpose, but synchronization should in my opinion be performed using the 
monotonic clock, as the wall time can jump around. I believe drivers should 
provide monotonic timestamps only. However, given that the uvcvideo driver has 
the option of providing wall clock timestamps, that option should work, so 
your patch makes sense. I'd still like to remove support for the wall clock 
though, but I don't want to break userspace. ffmpeg should be fixed, 
especially given that most V4L devices provide monotonic timestamps only.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] v4l2-compliance: fix function pointer prototype

2014-04-01 Thread Prabhakar Lad 
Hi Hans,

On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil hansv...@cisco.com wrote:
 Hi Prabhakar,

 On 04/01/14 15:45, Lad, Prabhakar wrote:
 From: Lad, Prabhakar prabhakar.cse...@gmail.com

 There was a conflict between the mmap function pointer prototype of
 struct v4l_fd and the actual function used. Make sure it is in sync
 with the prototype of v4l2_mmap.

 The prototype of v4l2_mmap uses int64_t, so I don't understand this
 patch.

Actual prototype of mmap is,

  void *mmap(void *addr, size_t length, int prot, int flags, int fd,
off_t offset);

But where as the prototype in v4l_fd mmap the last parameter type is int64_t
but that should have been off_t and same applies with test_mmap().

Thanks,
--Prabhakar Lad
--
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 0/5] s5p-fimc: Misc fixes

2014-04-01 Thread Nicolas Dufresne 
Any comment/input ?

Le mardi 25 mars 2014 à 16:45 -0400, Nicolas Dufresne a écrit :
 This patch series fixes several bugs found in the s5p-fimc driver. These
 bugs relate to bad parameters in the formats definition and short size
 of image buffers.
 
 Nicolas Dufresne (5):
   s5p-fimc: Reuse calculated sizes
   s5p-fimc: Iterate for each memory plane
   s5p-fimc: Align imagesize to row size for tiled formats
   s5p-fimc: Fix YUV422P depth
   s5p-fimc: Changed RGB32 to BGR32
 
  drivers/media/platform/exynos4-is/fimc-core.c | 21 +++--
  drivers/media/platform/exynos4-is/fimc-m2m.c  |  6 +++---
  2 files changed, 18 insertions(+), 9 deletions(-)
 



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 0/5] s5p-fimc: Misc fixes

2014-04-01 Thread Sylwester Nawrocki 
Hi Nicolas,

On 01/04/14 16:13, Nicolas Dufresne wrote:
 Any comment/input ?

My apologies for the delay. The patches look good to me, I'm going
to apply them to my tree for 3.16, as the media tree is already closed
for 3.15. Thanks a lot for these fixes!

 Le mardi 25 mars 2014 à 16:45 -0400, Nicolas Dufresne a écrit :
 This patch series fixes several bugs found in the s5p-fimc driver. These
 bugs relate to bad parameters in the formats definition and short size
 of image buffers.

 Nicolas Dufresne (5):
   s5p-fimc: Reuse calculated sizes
   s5p-fimc: Iterate for each memory plane
   s5p-fimc: Align imagesize to row size for tiled formats
   s5p-fimc: Fix YUV422P depth
   s5p-fimc: Changed RGB32 to BGR32

  drivers/media/platform/exynos4-is/fimc-core.c | 21 +++--
  drivers/media/platform/exynos4-is/fimc-m2m.c  |  6 +++---
  2 files changed, 18 insertions(+), 9 deletions(-)


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

Re: [PATCH] Fix _IOC_TYPECHECK sparse error

2014-04-01 Thread Josh Triplett 
On Tue, Apr 01, 2014 at 09:04:12AM +0200, Hans Verkuil wrote:
 When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these
 errors:
 
 drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant 
 expression
 drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant 
 expression
 drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant 
 expression
 drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant 
 expression
 
 etc.
 
 The root cause of that turns out to be in include/asm-generic/ioctl.h:
 
 #include uapi/asm-generic/ioctl.h
 
 /* provoke compile error for invalid uses of size argument */
 extern unsigned int __invalid_size_argument_for_IOC;
 #define _IOC_TYPECHECK(t) \
 ((sizeof(t) == sizeof(t[1])  \
   sizeof(t)  (1  _IOC_SIZEBITS)) ? \
   sizeof(t) : __invalid_size_argument_for_IOC)
 
 If it is defined as this (as is already done if __KERNEL__ is not defined):
 
 #define _IOC_TYPECHECK(t) (sizeof(t))
 
 then all is well with the world.
 
 This patch allows sparse to work correctly.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com

Reviewed-by: Josh Triplett j...@joshtriplett.org

 diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h
 index d17295b..297fb0d 100644
 --- a/include/asm-generic/ioctl.h
 +++ b/include/asm-generic/ioctl.h
 @@ -3,10 +3,15 @@
  
  #include uapi/asm-generic/ioctl.h
  
 +#ifdef __CHECKER__
 +#define _IOC_TYPECHECK(t) (sizeof(t))
 +#else
  /* provoke compile error for invalid uses of size argument */
  extern unsigned int __invalid_size_argument_for_IOC;
  #define _IOC_TYPECHECK(t) \
   ((sizeof(t) == sizeof(t[1])  \
 sizeof(t)  (1  _IOC_SIZEBITS)) ? \
 sizeof(t) : __invalid_size_argument_for_IOC)
 +#endif
 +
  #endif /* _ASM_GENERIC_IOCTL_H */
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-sparse in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l2-compliance: fix function pointer prototype

2014-04-01 Thread Hans Verkuil 


On 04/01/14 16:06, Prabhakar Lad wrote:
 Hi Hans,
 
 On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil hansv...@cisco.com wrote:
 Hi Prabhakar,

 On 04/01/14 15:45, Lad, Prabhakar wrote:
 From: Lad, Prabhakar prabhakar.cse...@gmail.com

 There was a conflict between the mmap function pointer prototype of
 struct v4l_fd and the actual function used. Make sure it is in sync
 with the prototype of v4l2_mmap.

 The prototype of v4l2_mmap uses int64_t, so I don't understand this
 patch.

 Actual prototype of mmap is,
 
   void *mmap(void *addr, size_t length, int prot, int flags, int fd,
 off_t offset);
 
 But where as the prototype in v4l_fd mmap the last parameter type is int64_t
 but that should have been off_t and same applies with test_mmap().

The problem is that v4l2_mmap (in lib/include/libv4l2.h) uses int64_t.
So the function pointer uses int64_t as well as does test_mmap.

I don't see how the current v4l-utils tree can cause a compile error.

For the record, I know you can't assign mmap to fd-mmap, you would
have to make a wrapper. Unfortunately mmap and v4l2_mmap do not have
the same prototype and I had to pick one (I'm not sure why they don't
use the same prototype).

Most applications would typically have to use v4l2_mmap, so I went with
that one.

Regards,

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

Re: [PATCH 1/5] s5p-fimc: Changed RGB32 to BGR32

2014-04-01 Thread Sylwester Nawrocki 
On 25/03/14 21:55, Nicolas Dufresne wrote:
 Testing showed that HW produces BGR32 rather then RGB32 as exposed
 in the driver. The documentation seems to state the pixels are stored
 in little endian order.
 
 Signed-off-by: Nicolas Dufresne nicolas.dufre...@collabora.com
 ---
  drivers/media/platform/exynos4-is/fimc-core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/platform/exynos4-is/fimc-core.c 
 b/drivers/media/platform/exynos4-is/fimc-core.c
 index da2fc86..bfb80fb 100644
 --- a/drivers/media/platform/exynos4-is/fimc-core.c
 +++ b/drivers/media/platform/exynos4-is/fimc-core.c
 @@ -56,8 +56,8 @@ static struct fimc_fmt fimc_formats[] = {
   .colplanes  = 1,
   .flags  = FMT_FLAGS_M2M,
   }, {
 - .name   = ARGB, 32 bpp,
 - .fourcc = V4L2_PIX_FMT_RGB32,
 + .name   = BGRB888, 32 bpp,

It should be BGRA, 32 bpp, I can fix it when applying, if
you won't send next version of this patch until then.

 + .fourcc = V4L2_PIX_FMT_BGR32,
   .depth  = { 32 },
   .color  = FIMC_FMT_RGB888,
   .memplanes  = 1,

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

[patch] [media] dvb-core: check -msg_len for diseqc_send_master_cmd()

2014-04-01 Thread Dan Carpenter 
I'd like to send this patch except that it breaks
cx24116_send_diseqc_msg().  The cx24116 driver accepts -msg_len values
up to 24 but it looks like it's just copying 16 bytes past the end of
the -msg[] array so it's already broken.

cmd-msg_len is an unsigned char.  The comment next to the struct
declaration says that valid values are are 3-6.  Some of the drivers
check that this is true, but most don't and it could cause memory
corruption.

Some examples of functions which don't check are:
ttusbdecfe_dvbs_diseqc_send_master_cmd()
cx24123_send_diseqc_msg()
ds3000_send_diseqc_msg()
etc.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Reviewed-by: Antti Palosaari cr...@iki.fi
---
This is a static checker fix and I haven't tested it but the security
implications are quite bad so we should fix this.

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 57601c0..3d1eee6 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2267,7 +2267,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 
case FE_DISEQC_SEND_MASTER_CMD:
if (fe-ops.diseqc_send_master_cmd) {
-   err = fe-ops.diseqc_send_master_cmd(fe, (struct 
dvb_diseqc_master_cmd*) parg);
+   struct dvb_diseqc_master_cmd *cmd = parg;
+
+   if (cmd-msg_len = 3  cmd-msg_len = 6)
+   err = fe-ops.diseqc_send_master_cmd(fe, cmd);
+   else
+   err = -EINVAL;
+
fepriv-state = FESTATE_DISEQC;
fepriv-status = 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] v4l2-compliance: fix function pointer prototype

2014-04-01 Thread Hans Verkuil 
On 04/01/14 16:26, Hans Verkuil wrote:
 
 
 On 04/01/14 16:06, Prabhakar Lad wrote:
 Hi Hans,

 On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil hansv...@cisco.com wrote:
 Hi Prabhakar,

 On 04/01/14 15:45, Lad, Prabhakar wrote:
 From: Lad, Prabhakar prabhakar.cse...@gmail.com

 There was a conflict between the mmap function pointer prototype of
 struct v4l_fd and the actual function used. Make sure it is in sync
 with the prototype of v4l2_mmap.

 The prototype of v4l2_mmap uses int64_t, so I don't understand this
 patch.

 Actual prototype of mmap is,

   void *mmap(void *addr, size_t length, int prot, int flags, int fd,
 off_t offset);

 But where as the prototype in v4l_fd mmap the last parameter type is int64_t
 but that should have been off_t and same applies with test_mmap().
 
 The problem is that v4l2_mmap (in lib/include/libv4l2.h) uses int64_t.
 So the function pointer uses int64_t as well as does test_mmap.
 
 I don't see how the current v4l-utils tree can cause a compile error.
 
 For the record, I know you can't assign mmap to fd-mmap, you would
 have to make a wrapper. Unfortunately mmap and v4l2_mmap do not have
 the same prototype and I had to pick one (I'm not sure why they don't
 use the same prototype).
 
 Most applications would typically have to use v4l2_mmap, so I went with
 that one.
 

I missed that mmap is assigned to v4l_fd_init(). Since mmap and v4l2_mmap
have different prototypes the only solution is to make a wrapper.

Does this work?

diff --git a/utils/v4l2-compliance/v4l-helpers.h 
b/utils/v4l2-compliance/v4l-helpers.h
index 48ea602..e718a24 100644
--- a/utils/v4l2-compliance/v4l-helpers.h
+++ b/utils/v4l2-compliance/v4l-helpers.h
@@ -14,11 +14,21 @@ struct v4l_fd {
int (*munmap)(void *addr, size_t length);
 };
 
+/*
+ * mmap has a different prototype compared to v4l2_mmap. Because of
+ * this we have to make a wrapper for it.
+ */
+static inline void *v4l_fd_mmap(void *addr, size_t length, int prot, int flags,
+ int fd, int64_t offset)
+{
+   return mmap(addr, length, prot, flags, fd, offset);
+}
+
 static inline void v4l_fd_init(struct v4l_fd *f, int fd)
 {
f-fd = fd;
f-ioctl = ioctl;
-   f-mmap = mmap;
+   f-mmap = v4l_fd_mmap;
f-munmap = munmap;
 }
 

On a 64-bit system the types are the same, it's only on a 32-bit system that
this will fail.

Regards,

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

Re: [PATCH] v4l2-compliance: fix function pointer prototype

2014-04-01 Thread Prabhakar Lad 
Hi Hans,

On Tue, Apr 1, 2014 at 8:12 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On 04/01/14 16:26, Hans Verkuil wrote:


 On 04/01/14 16:06, Prabhakar Lad wrote:
 Hi Hans,

 On Tue, Apr 1, 2014 at 7:20 PM, Hans Verkuil hansv...@cisco.com wrote:
 Hi Prabhakar,

 On 04/01/14 15:45, Lad, Prabhakar wrote:
 From: Lad, Prabhakar prabhakar.cse...@gmail.com

 There was a conflict between the mmap function pointer prototype of
 struct v4l_fd and the actual function used. Make sure it is in sync
 with the prototype of v4l2_mmap.

 The prototype of v4l2_mmap uses int64_t, so I don't understand this
 patch.

 Actual prototype of mmap is,

   void *mmap(void *addr, size_t length, int prot, int flags, int fd,
 off_t offset);

 But where as the prototype in v4l_fd mmap the last parameter type is int64_t
 but that should have been off_t and same applies with test_mmap().

 The problem is that v4l2_mmap (in lib/include/libv4l2.h) uses int64_t.
 So the function pointer uses int64_t as well as does test_mmap.

 I don't see how the current v4l-utils tree can cause a compile error.

 For the record, I know you can't assign mmap to fd-mmap, you would
 have to make a wrapper. Unfortunately mmap and v4l2_mmap do not have
 the same prototype and I had to pick one (I'm not sure why they don't
 use the same prototype).

 Most applications would typically have to use v4l2_mmap, so I went with
 that one.


 I missed that mmap is assigned to v4l_fd_init(). Since mmap and v4l2_mmap
 have different prototypes the only solution is to make a wrapper.

 Does this work?

Yes it compiles now with the below patch.

Thanks,
--Prabhakar Lad

 diff --git a/utils/v4l2-compliance/v4l-helpers.h 
 b/utils/v4l2-compliance/v4l-helpers.h
 index 48ea602..e718a24 100644
 --- a/utils/v4l2-compliance/v4l-helpers.h
 +++ b/utils/v4l2-compliance/v4l-helpers.h
 @@ -14,11 +14,21 @@ struct v4l_fd {
 int (*munmap)(void *addr, size_t length);
  };

 +/*
 + * mmap has a different prototype compared to v4l2_mmap. Because of
 + * this we have to make a wrapper for it.
 + */
 +static inline void *v4l_fd_mmap(void *addr, size_t length, int prot, int 
 flags,
 + int fd, int64_t offset)
 +{
 +   return mmap(addr, length, prot, flags, fd, offset);
 +}
 +
  static inline void v4l_fd_init(struct v4l_fd *f, int fd)
  {
 f-fd = fd;
 f-ioctl = ioctl;
 -   f-mmap = mmap;
 +   f-mmap = v4l_fd_mmap;
 f-munmap = munmap;
  }


 On a 64-bit system the types are the same, it's only on a 32-bit system that
 this will fail.

 Regards,

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

Re: [patch] [media] dvb-core: check -msg_len for diseqc_send_master_cmd()

2014-04-01 Thread Dan Carpenter 
Oops.  I send this to Mauro's old email address.  Sorry about that.

regards,
dan carpenter

On Tue, Apr 01, 2014 at 05:38:07PM +0300, Dan Carpenter wrote:
 I'd like to send this patch except that it breaks
 cx24116_send_diseqc_msg().  The cx24116 driver accepts -msg_len values
 up to 24 but it looks like it's just copying 16 bytes past the end of
 the -msg[] array so it's already broken.
 
 cmd-msg_len is an unsigned char.  The comment next to the struct
 declaration says that valid values are are 3-6.  Some of the drivers
 check that this is true, but most don't and it could cause memory
 corruption.
 
 Some examples of functions which don't check are:
 ttusbdecfe_dvbs_diseqc_send_master_cmd()
 cx24123_send_diseqc_msg()
 ds3000_send_diseqc_msg()
 etc.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 Reviewed-by: Antti Palosaari cr...@iki.fi
 ---
 This is a static checker fix and I haven't tested it but the security
 implications are quite bad so we should fix this.
 
 diff --git a/drivers/media/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb-core/dvb_frontend.c
 index 57601c0..3d1eee6 100644
 --- a/drivers/media/dvb-core/dvb_frontend.c
 +++ b/drivers/media/dvb-core/dvb_frontend.c
 @@ -2267,7 +2267,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
  
   case FE_DISEQC_SEND_MASTER_CMD:
   if (fe-ops.diseqc_send_master_cmd) {
 - err = fe-ops.diseqc_send_master_cmd(fe, (struct 
 dvb_diseqc_master_cmd*) parg);
 + struct dvb_diseqc_master_cmd *cmd = parg;
 +
 + if (cmd-msg_len = 3  cmd-msg_len = 6)
 + err = fe-ops.diseqc_send_master_cmd(fe, cmd);
 + else
 + err = -EINVAL;
 +
   fepriv-state = FESTATE_DISEQC;
   fepriv-status = 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/5] s5p-fimc: Changed RGB32 to BGR32

2014-04-01 Thread Nicolas Dufresne 
Le mardi 01 avril 2014 à 16:34 +0200, Sylwester Nawrocki a écrit :
 It should be BGRA, 32 bpp, I can fix it when applying, if
 you won't send next version of this patch until then.

Good catch, I'll let you fix when applying.

thanks,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: sparse: ioctl defines and error: bad integer constant expression

2014-04-01 Thread Christopher Li 
On Mon, Mar 31, 2014 at 10:22 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil hverk...@xs4all.nl wrote:

 Chris, can you please add this to the test cases since Hans did the
 work to create a nice small test-case?

Sure, I want to add them to the test case.

Hans, May I get a signed-off for your test cases?

Chris
--
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: sparse: ioctl defines and error: bad integer constant expression

2014-04-01 Thread Hans Verkuil 
On 04/01/2014 06:48 PM, Christopher Li wrote:
 On Mon, Mar 31, 2014 at 10:22 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:
 On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil hverk...@xs4all.nl wrote:

 Chris, can you please add this to the test cases since Hans did the
 work to create a nice small test-case?
 
 Sure, I want to add them to the test case.
 
 Hans, May I get a signed-off for your test cases?

For all my test cases:

Signed-off-by: Hans Verkuil hans.verk...@cisco.com

Regards,

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

Re: em2750 usb camera log as mentioned in dmesg

2014-04-01 Thread Frank Schäfer 

Am 28.03.2014 21:21, schrieb aaron.mo...@alsatis.net:
 Hi,

 I have endless problems since upgarding to ubuntu12.04 with my usb
 microscope and it's a big problem cos i need it for work.
Which device are you talking about ? Which sensor does it use ?
What does endless problems mean ?
Which kernel are you using and what's the last working kernel version ?


 As suggested in dmesg I have sent you the log..  Interestingly the
 em2750 camera is Ok on my desk pc with Xubuntu 12.04...  go figure..
 But the desk pC is kinda hard to carry to customer sites.

 I hope to find a solution soon

 thanks

 Aaron

 [12699.292580] em28xx: New device   @ 480 Mbps (eb1a:2750, interface
 0, class 0)
 [12699.292585] em28xx: Video interface 0 found: isoc
 [12699.292636] em28xx: chip ID is em2750
 [12699.476200] em2750 #0: board has no eeprom
 [12699.547792] em2750 #0: No sensor detected
As you can see, no sensor is found.
Does this also happen with the working kernel ?

Regards,
Frank Schäfer

 [12699.583014] em2750 #0: found i2c device @ 0xba on bus 0 [webcam
 sensor or tvp5150a]
 [12699.595736] em2750 #0: Your board has no unique USB ID and thus
 need a hint to be detected.
 [12699.595742] em2750 #0: You may try to use card=n insmod option to
 workaround that.
 [12699.595746] em2750 #0: Please send an email with this log to:
 [12699.595749] em2750 #0: V4L Mailing List
 linux-media@vger.kernel.org
 [12699.595752] em2750 #0: Board eeprom hash is 0x
 [12699.595756] em2750 #0: Board i2c devicelist hash is 0x1bdd0080
 [12699.595759] em2750 #0: Here is a list of valid choices for the
 card=n insmod option:
 [12699.595764] em2750 #0: card=0 - Unknown EM2800 video grabber
 [12699.595768] em2750 #0: card=1 - Unknown EM2750/28xx video grabber
 [12699.595772] em2750 #0: card=2 - Terratec Cinergy 250 USB
 [12699.595776] em2750 #0: card=3 - Pinnacle PCTV USB 2
 [12699.595779] em2750 #0: card=4 - Hauppauge WinTV USB 2
 [12699.595783] em2750 #0: card=5 - MSI VOX USB 2.0
 [12699.595786] em2750 #0: card=6 - Terratec Cinergy 200 USB
 [12699.595790] em2750 #0: card=7 - Leadtek Winfast USB II
 [12699.595793] em2750 #0: card=8 - Kworld USB2800
 [12699.595798] em2750 #0: card=9 - Pinnacle Dazzle DVC
 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 /
 Plextor ConvertX PX-AV100U
 [12699.595802] em2750 #0: card=10 - Hauppauge WinTV HVR 900
 [12699.595805] em2750 #0: card=11 - Terratec Hybrid XS
 [12699.595809] em2750 #0: card=12 - Kworld PVR TV 2800 RF
 [12699.595812] em2750 #0: card=13 - Terratec Prodigy XS
 [12699.595816] em2750 #0: card=14 - SIIG AVTuner-PVR / Pixelview
 Prolink PlayTV USB 2.0
 [12699.595819] em2750 #0: card=15 - V-Gear PocketTV
 [12699.595823] em2750 #0: card=16 - Hauppauge WinTV HVR 950
 [12699.595827] em2750 #0: card=17 - Pinnacle PCTV HD Pro Stick
 [12699.595830] em2750 #0: card=18 - Hauppauge WinTV HVR 900 (R2)
 [12699.595834] em2750 #0: card=19 - EM2860/SAA711X Reference Design
 [12699.595838] em2750 #0: card=20 - AMD ATI TV Wonder HD 600
 [12699.595841] em2750 #0: card=21 - eMPIA Technology, Inc.
 GrabBeeX+ Video Encoder
 [12699.595845] em2750 #0: card=22 - EM2710/EM2750/EM2751 webcam
 grabber
 [12699.595849] em2750 #0: card=23 - Huaqi DLCW-130
 [12699.595852] em2750 #0: card=24 - D-Link DUB-T210 TV Tuner
 [12699.595856] em2750 #0: card=25 - Gadmei UTV310
 [12699.595859] em2750 #0: card=26 - Hercules Smart TV USB 2.0
 [12699.595863] em2750 #0: card=27 - Pinnacle PCTV USB 2 (Philips
 FM1216ME)
 [12699.595867] em2750 #0: card=28 - Leadtek Winfast USB II Deluxe
 [12699.595870] em2750 #0: card=29 - EM2860/TVP5150 Reference Design
 [12699.595874] em2750 #0: card=30 - Videology 20K14XUSB USB2.0
 [12699.595877] em2750 #0: card=31 - Usbgear VD204v9
 [12699.595881] em2750 #0: card=32 - Supercomp USB 2.0 TV
 [12699.595884] em2750 #0: card=33 - Elgato Video Capture
 [12699.595888] em2750 #0: card=34 - Terratec Cinergy A Hybrid XS
 [12699.595891] em2750 #0: card=35 - Typhoon DVD Maker
 [12699.595895] em2750 #0: card=36 - NetGMBH Cam
 [12699.595898] em2750 #0: card=37 - Gadmei UTV330
 [12699.595902] em2750 #0: card=38 - Yakumo MovieMixer
 [12699.595906] em2750 #0: card=39 - KWorld PVRTV 300U
 [12699.595909] em2750 #0: card=40 - Plextor ConvertX PX-TV100U
 [12699.595913] em2750 #0: card=41 - Kworld 350 U DVB-T
 [12699.595916] em2750 #0: card=42 - Kworld 355 U DVB-T
 [12699.595920] em2750 #0: card=43 - Terratec Cinergy T XS
 [12699.595924] em2750 #0: card=44 - Terratec Cinergy T XS (MT2060)
 [12699.595927] em2750 #0: card=45 - Pinnacle PCTV DVB-T
 [12699.595931] em2750 #0: card=46 - Compro, VideoMate U3
 [12699.595934] em2750 #0: card=47 - KWorld DVB-T 305U
 [12699.595938] em2750 #0: card=48 - KWorld DVB-T 310U
 [12699.595941] em2750 #0: card=49 - MSI DigiVox A/D
 [12699.595945] em2750 #0: card=50 - MSI

Re: [PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

2014-04-01 Thread Laurent Pinchart 
Hi Jean-François,

Sorry for the late reply.

On Thursday 27 March 2014 12:34:49 Jean-Francois Moine wrote:
 On Wed, 26 Mar 2014 18:33:09 +0100 Laurent Pinchart wrote:
  That could work in your case, but I don't really like that.
  
  We need to describe the hardware topology, that might be the only point we
  all agree on. There are various hardware topologies we need to support
  with different levels of complexity, and several ways to describe them,
  also with a wide range of complexities and features.
  
  The more complex the hardware topology, the more complex its description
  needs to be, and the more complex the code that will parse the
  description and handle the hardware will be. I don't think there's any
  doubt here.

 But also, the simpler is the topology and the simpler should be its
 description.

I wouldn't put it so strongly. I believe we can slightly relax our 
requirements regarding DT bindings complexity as long as drivers remain 
simple. There's of course no reason to use more complex bindings just for the 
sake of it.

 In your approach, the connections between endpoints are described in the
 components themselves, which makes hard for the DT maintainers to have a
 global understanding of the video subsystem.
 
 Having the topology described in the master device is clearer, even if it is
 complex.

First of all, let's clarify what a master device is. In the simple-video-
card example you've proposed the master device is a logical device (with a DT 
node that has no corresponding hardware device). The second approach I can 
think of is to make the IP core that implements the CRTC (which I usually call 
display controller) be the master device. Let's note that the second case 
makes both the link and global description DT binding styles possible.

My concern with the global description bindings style is that the approach 
only applies to simple hardware and can't be generalized. Now, I'm not too 
concerned about using that approach for simple hardware and a link-based 
approach for more complex hardware. The slave components, however, need to 
use a single DT bindings style, regardless of the DT bindings used by the 
master device. That's why I believe we should try to standardize one DT 
bindings style for master devices, even if it results in a slightly more 
complex DT description than strictly needed in some cases.

  A given device can be integrated in a wide variety of hardware with
  different complexities. A driver can't thus always assume that the whole
  composite display device will match a given class of topologies. This is
  especially true for encoders and connectors, they can be hooked up
  directly at the output of a very simple display controller, or can be
  part of a very complex graph. Encoder and connector drivers can't assume
  much about how they will be integrated. I want to avoid a situation where
  using an HDMI encoder already supported in mainline with a different SoC
  will result in having to rewrite the HDMI encoder driver.
 
 The tda998x chips are simple enough for being used in many boards: one video
 input and one serial digital output. I don't see in which circumstance the
 driver should be rewritten.

It shouldn't, that's the whole point ;-) I wasn't talking about the tda998x 
only, but about encoder drivers in general. I have a display controller in a 
Renesas SoC that has two LVDS encoders that output LVDS signals out of the 
SoC. One LVDS port is connected to an LVDS panel (a connector from a DRM point 
of view), the second one to an LVDS receiver that outputs parallel RGB data to 
an HDMI encoder. The LVDS encoder can't thus assume any particular downstream 
topology and its driver thus can't create DRM encoder and connector instances. 
The same could be true for an HDMI encoder in theory, although an HDMI encoder 
connected on the same board directly to an HDMI decoder that outputs RGB data 
to a panel is probably a case that will be rarely seen in practice.

In the general case an encoder driver can't assume any specific upstream or 
downstream topology. As long as DRM can't expose the real hardware topology to 
userspace, someone needs to decide on how to map the hardware topology to the 
DRM topology exposed to userspace. Encoder drivers can't take that role and 
thus shouldn't create DRM encoder and connector instances themselves.

  The story is a bit different for display controllers. While the hardware
  topology outside (and sometimes inside as well) of the SoC can vary, a
  display controller often approximately implies a given level of
  complexity. A cheap SoC with a simple display controller will likely not
  be used to drive a 4k display requiring 4 encoders running in parallel
  for instance. While I also want to avoid having to make significant
  changes to a display controller driver when using the SoC on a different
  board, I believe the requirement can be slightly relaxed here, and the
  display controller driver(s) can

Re: [PATCH] [media] uvcvideo: Fix marking buffer erroneous in case of FID toggling

2014-04-01 Thread Laurent Pinchart 
Hi Anton,

On Saturday 29 March 2014 09:28:02 Anton Leontiev wrote:
 28.03.2014 20:12, Laurent Pinchart пишет:
  + * Set error flag for incomplete buffer.
  + */
  +static void uvc_buffer_check_bytesused(const struct uvc_streaming
  *const stream,
  
  No need for the second const keyword here.
  
  I would have used uvc_video_ as a prefix, to be in sync with the
  surrounding functions. What would you think of
  uvc_video_validate_buffer() ?
  
  +struct uvc_buffer *const buf)
  
  And no need for const at all here.
  
  +{
  +if (buf-length != buf-bytesused 
  +!(stream-cur_format-flags  
  UVC_FMT_FLAG_COMPRESSED))
  
  The indentation is wrong here, the ! on the second line should be aligned
  to the first 'buf' of the first line.
  
  If you agree with these changes I can perform them while applying, there's
  no need to resubmit the patch.
 
 Thank you for reviewing my first patch to Linux kernel.

Thank you for submitting it :-)

 I completely agree with your changes.
 
 Just want to ask why there is no need for the second 'const' after pointer
 character '*'? I thought it marks pointer itself as constant for type-
 checking opposite to first 'const', which marks memory it points to as
 constant for type-checking.

Your understanding is correct (as far as I know).

 I understand that the function is simple enough to verify it by hand but
 it's better to add more information for automatic checking.

 Is there any guidelines on 'const' keyword usage in Linux kernel code?

Marking the memory pointed to by the pointer as const ensures that the 
function won't modify memory that the caller thought wouldn't be modified. It 
thus serves as a contract between the caller and the callee, enforced by the 
compiler.

Marking the pointer as const, on the other hand, only affects the function 
implementation, without influencing its call contract. Its only use in this 
case would be to prevent the function from modifying a pointer that the 
function itself thought it shouldn't modify. While not useless in all cases, 
this compile-time checked if usually not performed in the kernel, especially 
for simple functions. I'm not aware of any explicit rule regarding const usage 
though.

-- 
Regards,

Laurent Pinchart

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

Re: Writing a HDMI-CEC device driver for the IT66121

2014-04-01 Thread Sriakhil Gogineni 
Hi Hans,

Thanks for the detailed response. As, much as I would love to have a robust, 
fully functioning implementation for v1, I  think it might be a a bit of 
'over-optimization' to write the complete spec into the driver from the 
beginning.

The question I ask myself is, how can we get it mainlined quickly? I'm not 
sure of the answer but I would like implement and test basic features of 
HDMI-CEC and then add in the more advanced fun stuff ;)

So I'm trying to test out CEC on the hardware I have. Making clean interfaces 
would allow for adaptable between 4l2 devices, drm/kms devices and hardware. My 
question is how can I connect to / test on the hardware I have?

Best,
Sri

On Apr 1, 2014, at 2:29 AM, Hans Verkuil hverk...@xs4all.nl wrote:

 Hi Sri,
 
 On 03/31/14 23:12, Sriakhil Gogineni wrote:
 Hi,
 
 I'm trying to write a HDMI-CEC driver for the Radxa Rock
 (Specification - Radxa). I am coming from a software background and
 have found libcec and am looking at other implementation.
 
 I'm wondering how to connect the hardware and software pieces under
 Linux / Android.
 
 I'm not sure if I need to find out what /dev/ its exposed under via
 the device tree or determine which register is used from the data
 sheet?
 
 Any advice / tips / pointers would be helpful.
 
 There is currently no kernel CEC support available. What makes cec
 complex is 1) the CEC specification is horrible :-) and 2) a proper cec
 implementation has to be able to take care of v4l2 devices, drm/kms devices
 and usb dongles. In addition, at least some of the CEC handling has to
 take place in the kernel in order to handle the audio return channel,
 suspend commands, hotplug-over-CEC and such advanced features.
 
 I have been working on this, but it is a background project and I never
 found the time to finish it.
 
 My latest code is available here:
 
 http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cec
 
 but it needs more work to make this ready for prime time.
 
 It works, but it needs cleanup and cec_claim_log_addrs() needs improvement.
 Particularly when called from a driver: this needs to be done in non-
 blocking mode which isn't yet working (in blocking mode the driver would
 block for an unacceptable amount of time).
 
 If you or someone else would be willing to take over, I would have no
 objections. I have no idea when I might have time to continue work on
 this.
 
 Regards,
 
   Hans

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

Re: [yavta PATCH 3/9] Allow supporting mem2mem devices by adding forced OUTPUT device type

2014-04-01 Thread Laurent Pinchart 
Hi Sakari,

Thank you for the patch.

On Saturday 01 March 2014 18:18:04 Sakari Ailus wrote:
 The option is --output, or -o.

Wouldn't it make sense to have an option to force the device type to a user-
specified value instead of just an option for the output type ? -o is also 
usually used to select an output file, I'd like to keep it for that.

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  yavta.c |   10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/yavta.c b/yavta.c
 index 8e43ce5..e010252 100644
 --- a/yavta.c
 +++ b/yavta.c
 @@ -1240,6 +1240,7 @@ static void usage(const char *argv0)
   printf(-I, --fill-frames   Fill frames with check pattern 
 before 
queuing
 them\n); printf(-l, --list-controls List available controls\n);
   printf(-n, --nbufs n   Set the number of video 
 buffers\n);
 + printf(-o, --outputUse video node as output\n);
   printf(-p, --pause Pause before starting the video 
stream\n);
   printf(-q, --quality n MJPEG quality (0-100)\n);
   printf(-r, --get-control ctrl  Get control 'ctrl'\n);
 @@ -1282,6 +1283,7 @@ static struct option opts[] = {
   {nbufs, 1, 0, 'n'},
   {no-query, 0, 0, OPT_NO_QUERY},
   {offset, 1, 0, OPT_USERPTR_OFFSET},
 + {output, 0, 0, 'o'},
   {pause, 0, 0, 'p'},
   {quality, 1, 0, 'q'},
   {get-control, 1, 0, 'r'},
 @@ -1304,7 +1306,7 @@ int main(int argc, char *argv[])
   int ret;
 
   /* Options parsings */
 - int do_file = 0, do_capture = 0, do_pause = 0;
 + int do_file = 0, do_capture = 0, do_pause = 0, do_output = 0;
   int do_set_time_per_frame = 0;
   int do_enum_formats = 0, do_set_format = 0;
   int do_enum_inputs = 0, do_set_input = 0;
 @@ -1385,6 +1387,9 @@ int main(int argc, char *argv[])
   if (nbufs  V4L_BUFFERS_MAX)
   nbufs = V4L_BUFFERS_MAX;
   break;
 + case 'o':
 + do_output = 1;
 + break;
   case 'p':
   do_pause = 1;
   break;
 @@ -1500,6 +1505,9 @@ int main(int argc, char *argv[])
   if (dev.type == (enum v4l2_buf_type)-1)
   no_query = 1;
 
 + if (do_output)
 + dev.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
 +
   dev.memtype = memtype;
 
   if (do_get_control) {

-- 
Regards,

Laurent Pinchart

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

Re: [yavta PATCH 5/9] Allow passing file descriptors to yavta

2014-04-01 Thread Laurent Pinchart 
Hi Sakari,

Thank you for the patch.

On Saturday 01 March 2014 18:18:06 Sakari Ailus wrote:
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  yavta.c |   63 
  1 file changed, 43 insertions(+), 20 deletions(-)
 
 diff --git a/yavta.c b/yavta.c
 index 870682e..a9b192a 100644
 --- a/yavta.c
 +++ b/yavta.c
 @@ -62,6 +62,7 @@ struct buffer
  struct device
  {
   int fd;
 + int opened;
 
   enum v4l2_buf_type type;
   enum v4l2_memory memtype;
 @@ -180,13 +181,8 @@ static unsigned int v4l2_format_code(const char *name)
   return 0;
  }
 
 -static int video_open(struct device *dev, const char *devname, int
 no_query)
 +static int video_open(struct device *dev, const char *devname)
  {
 - dev-fd = -1;
 - dev-memtype = V4L2_MEMORY_MMAP;
 - dev-buffers = NULL;
 - dev-type = (enum v4l2_buf_type)-1;
 -
   dev-fd = open(devname, O_RDWR);
   if (dev-fd  0) {
   printf(Error opening device %s: %s (%d).\n, devname,
 @@ -196,6 +192,16 @@ static int video_open(struct device *dev, const char
 *devname, int no_query)
 
   printf(Device %s opened.\n, devname);
 
 + dev-opened = 1;
 +
 + return 0;
 +}
 +
 +static int video_querycap(struct device *dev, int no_query) {
 + struct v4l2_capability cap;
 + unsigned int capabilities;
 + int ret;
 +

video_querycap ends up setting the dev-type field, which isn't really the job 
of a query function. Would there be a clean way to pass the fd to the 
video_open() function instead ? Maybe video_open() could be split and/or 
renamed to video_init() ?

   if (no_query) {
   /* Assume capture device. */
   dev-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
 @@ -215,9 +221,7 @@ static int video_open(struct device *dev, const char
 *devname, int no_query) else if (capabilities  V4L2_CAP_VIDEO_OUTPUT)
   dev-type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
   else {
 - printf(Error opening device %s: neither video capture 
 - nor video output supported.\n, devname);
 - close(dev-fd);
 + printf(Device supports neither capture nor output.\n);
   return -EINVAL;
   }
 
 @@ -231,7 +235,8 @@ static void video_close(struct device *dev)
  {
   free(dev-pattern);
   free(dev-buffers);
 - close(dev-fd);
 + if (dev-opened)
 + close(dev-fd);
  }
 
  static unsigned int get_control_type(struct device *dev, unsigned int id)
 @@ -1246,6 +1251,7 @@ static void usage(const char *argv0)
   printf(-w, --set-control 'ctrl value'  Set control 'ctrl' to 
'value'\n);
   printf(--enum-formats  Enumerate formats\n);
   printf(--enum-inputs   Enumerate inputs\n);
 + printf(--fdUse a numeric file descriptor
 insted of a device\n);
   printf(--no-query  Don't query capabilities on 
 open\n);
   printf(--offsetUser pointer buffer offset from 
 page
 start\n);
   printf(--requeue-last  Requeue the last buffers before
 streamoff\n);
 @@ -1262,6 +1268,7 @@ static void usage(const char *argv0)
  #define OPT_USERPTR_OFFSET   261
  #define OPT_REQUEUE_LAST 262
  #define OPT_STRIDE   263
 +#define OPT_FD   264
 
  static struct option opts[] = {
   {capture, 2, 0, 'c'},
 @@ -1269,6 +1276,7 @@ static struct option opts[] = {
   {delay, 1, 0, 'd'},
   {enum-formats, 0, 0, OPT_ENUM_FORMATS},
   {enum-inputs, 0, 0, OPT_ENUM_INPUTS},
 + {fd, 1, 0, OPT_FD},
   {file, 2, 0, 'F'},
   {fill-frames, 0, 0, 'I'},
   {format, 1, 0, 'f'},
 @@ -1297,7 +1305,11 @@ static struct option opts[] = {
  int main(int argc, char *argv[])
  {
   struct sched_param sched;
 - struct device dev = { 0 };
 + struct device dev = {
 + .fd = -1,
 + .memtype = V4L2_MEMORY_MMAP,
 + .type = (enum v4l2_buf_type)-1,
 + };
   int ret;
 
   /* Options parsings */
 @@ -1452,6 +1464,14 @@ int main(int argc, char *argv[])
   case OPT_ENUM_INPUTS:
   do_enum_inputs = 1;
   break;
 + case OPT_FD:
 + dev.fd = atoi(optarg);
 + if (dev.fd  0) {
 + printf(Bad file descriptor %d\n, dev.fd);
 + return 1;
 + }
 + printf(Using file descriptor %d\n, dev.fd);
 + break;
   case OPT_NO_QUERY:
   no_query = 1;
   break;
 @@ -1482,18 +1502,21 @@ int main(int argc, char *argv[])
   return 1;
   }
 
 - if (optind = argc) {
 - usage(argv[0]);
 - return 1;
 - }
 -
   if (!do_file)
   filename = NULL;
 
 - /* Open the video

Re: [yavta PATCH 6/9] Timestamp source for output buffers

2014-04-01 Thread Laurent Pinchart 
Hi Sakari,

Thank you for the patch.

On Saturday 01 March 2014 18:18:07 Sakari Ailus wrote:
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  yavta.c |   18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)
 
 diff --git a/yavta.c b/yavta.c
 index a9b192a..71c1477 100644
 --- a/yavta.c
 +++ b/yavta.c
 @@ -73,6 +73,7 @@ struct device
   unsigned int height;
   unsigned int bytesperline;
   unsigned int imagesize;
 + uint32_t buffer_output_flags;
 
   void *pattern;
   unsigned int patternsize;
 @@ -611,6 +612,7 @@ static int video_queue_buffer(struct device *dev, int
 index, enum buffer_fill_mo buf.m.userptr = (unsigned
 long)dev-buffers[index].mem;
 
   if (dev-type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
 + buf.flags = dev-buffer_output_flags;
   buf.bytesused = dev-patternsize;
   memcpy(dev-buffers[buf.index].mem, dev-pattern, 
 dev-patternsize);
   } else {
 @@ -1255,6 +1257,7 @@ static void usage(const char *argv0)
   printf(--no-query  Don't query capabilities on 
 open\n);
   printf(--offsetUser pointer buffer offset from 
 page
 start\n);
   printf(--requeue-last  Requeue the last buffers before
 streamoff\n);
 + printf(--timestamp-source  Set timestamp source on output
 buffers [eof, soe]\n);
   printf(--skip nSkip the first n frames\n);
   printf(--sleep-forever Sleep forever after configuring 
 the
 device\n); printf(--stride valueLine stride in 
 bytes\n);
 @@ -1269,6 +1272,7 @@ static void usage(const char *argv0)
  #define OPT_REQUEUE_LAST 262
  #define OPT_STRIDE   263
  #define OPT_FD   264
 +#define OPT_TSTAMP_SRC   265
 
  static struct option opts[] = {
   {capture, 2, 0, 'c'},
 @@ -1298,7 +1302,8 @@ static struct option opts[] = {
   {sleep-forever, 0, 0, OPT_SLEEP_FOREVER},
   {stride, 1, 0, OPT_STRIDE},
   {time-per-frame, 1, 0, 't'},
 - {userptr, 0, 0, 'u'},
 + {timestamp-source, 1, 0, OPT_TSTAMP_SRC},
 + {userptr, 1, 0, 'u'},

This seems to be an unrelated change.

   {0, 0, 0, 0}
  };
 
 @@ -1487,6 +1492,17 @@ int main(int argc, char *argv[])
   case OPT_STRIDE:
   stride = atoi(optarg);
   break;
 + case OPT_TSTAMP_SRC:
 + if (!strcmp(optarg, eof)) {
 + dev.buffer_output_flags |= 
 V4L2_BUF_FLAG_TSTAMP_SRC_EOF;

As the buffer_output_flags isn't used for anything else, would it make sense 
to just name it timestamp_source ?

 + } else if (!strcmp(optarg, soe)) {
 + dev.buffer_output_flags |= 
 V4L2_BUF_FLAG_TSTAMP_SRC_SOE;
 + } else {
 + printf(Invalid timestamp source %s\n, optarg);
 + return 1;
 + }
 + printf(Using %s timestamp source\n, optarg);

Do we really need this printf ?

 + break;
   case OPT_USERPTR_OFFSET:
   userptr_offset = atoi(optarg);
   break;

-- 
Regards,

Laurent Pinchart

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

Re: [yavta PATCH 0/9] Timestamp source and mem-to-mem device support

2014-04-01 Thread Laurent Pinchart 
Hi Sakari,

Thank you for the patches, and sorry for the late reply.

I've pushed outstanding multiplane patches to the master branch of the yavta 
repository, and applied the first two patches of this series on top of that. 
After addressing the commends I've made on the individual patches, could you 
please rebase the rest of the series and resend it ?

On Saturday 01 March 2014 18:18:01 Sakari Ailus wrote:
 Hi,
 
 This patchset enables using yavta for mem-to-mem devices, including
 mem2mem_testdev (or soon vim2m). The timestamp will be set for output
 buffers when the timestamp type is copy. An option is added to set the
 timestamp source flags (eof/soe).
 
 To use yavta for mem2mem devices, just open the device in the shell and pass
 the file descriptor to yavta (--fd).

-- 
Regards,

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

Re: [yavta PATCH 7/9] Print timestamp type and source for dequeued buffers

2014-04-01 Thread Laurent Pinchart 
Hi Sakari,

Thank you for the patch.

Given that the timestamp type and source are not supposed to change during 
streaming, do we really need to print them for every frame ?

On Saturday 01 March 2014 18:18:08 Sakari Ailus wrote:
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  yavta.c |   52 ++--
  1 file changed, 30 insertions(+), 22 deletions(-)
 
 diff --git a/yavta.c b/yavta.c
 index 71c1477..224405d 100644
 --- a/yavta.c
 +++ b/yavta.c
 @@ -445,6 +445,30 @@ static int video_set_framerate(struct device *dev,
 struct v4l2_fract *time_per_f return 0;
  }
 
 +static void get_ts_flags(uint32_t flags, const char **ts_type, const char
 **ts_source) +{
 + switch (flags  V4L2_BUF_FLAG_TIMESTAMP_MASK) {
 + case V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN:
 + *ts_type = unknown;
 + break;
 + case V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC:
 + *ts_type = monotonic;
 + break;
 + default:
 + *ts_type = invalid;
 + }
 + switch (flags  V4L2_BUF_FLAG_TSTAMP_SRC_MASK) {
 + case V4L2_BUF_FLAG_TSTAMP_SRC_EOF:
 + *ts_source = EoF;
 + break;
 + case V4L2_BUF_FLAG_TSTAMP_SRC_SOE:
 + *ts_source = SoE;
 + break;
 + default:
 + *ts_source = invalid;
 + }
 +}
 +
  static int video_alloc_buffers(struct device *dev, int nbufs,
   unsigned int offset, unsigned int padding)
  {
 @@ -488,26 +512,7 @@ static int video_alloc_buffers(struct device *dev, int
 nbufs, strerror(errno), errno);
   return ret;
   }
 - switch (buf.flags  V4L2_BUF_FLAG_TIMESTAMP_MASK) {
 - case V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN:
 - ts_type = unknown;
 - break;
 - case V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC:
 - ts_type = monotonic;
 - break;
 - default:
 - ts_type = invalid;
 - }
 - switch (buf.flags  V4L2_BUF_FLAG_TSTAMP_SRC_MASK) {
 - case V4L2_BUF_FLAG_TSTAMP_SRC_EOF:
 - ts_source = EoF;
 - break;
 - case V4L2_BUF_FLAG_TSTAMP_SRC_SOE:
 - ts_source = SoE;
 - break;
 - default:
 - ts_source = invalid;
 - }
 + get_ts_flags(buf.flags, ts_type, ts_source);
   printf(length: %u offset: %u timestamp type/source: %s/%s\n,
  buf.length, buf.m.offset, ts_type, ts_source);
 
 @@ -1131,6 +1136,7 @@ static int video_do_capture(struct device *dev,
 unsigned int nframes, last.tv_usec = start.tv_nsec / 1000;
 
   for (i = 0; i  nframes; ++i) {
 + const char *ts_type, *ts_source;
   /* Dequeue a buffer. */
   memset(buf, 0, sizeof buf);
   buf.type = dev-type;
 @@ -1163,10 +1169,12 @@ static int video_do_capture(struct device *dev,
 unsigned int nframes, fps = fps ? 100.0 / fps : 0.0;
 
   clock_gettime(CLOCK_MONOTONIC, ts);
 - printf(%u (%u) [%c] %u %u bytes %ld.%06ld %ld.%06ld %.3f 
 fps\n, i,
 buf.index, +  get_ts_flags(buf.flags, ts_type, ts_source);
 + printf(%u (%u) [%c] %u %u bytes %ld.%06ld %ld.%06ld %.3f fps 
 tstamp
 type/src %s/%s\n, i, buf.index, (buf.flags  V4L2_BUF_FLAG_ERROR) ? 'E' :
 '-',
   buf.sequence, buf.bytesused, buf.timestamp.tv_sec,
 - buf.timestamp.tv_usec, ts.tv_sec, ts.tv_nsec/1000, fps);
 + buf.timestamp.tv_usec, ts.tv_sec, ts.tv_nsec/1000, fps,
 + ts_type, ts_source);
 
   last = buf.timestamp;

-- 
Regards,

Laurent Pinchart

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

cron job: media_tree daily build: OK

2014-04-01 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:   Wed Apr  2 04:00:27 CEST 2014
git branch: test
git hash:   a83b93a7480441a47856dc9104bea970e84cda87
gcc version:i686-linux-gcc (GCC) 4.8.2
sparse version: v0.5.0
host hardware:  x86_64
host os:3.13-7.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: 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-3.13-i686: OK
linux-3.14-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
linux-3.13-x86_64: OK
linux-3.14-x86_64: OK
apps: OK
spec-git: OK
sparse version: v0.5.0
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.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

Re: [PATCH] [media] uvcvideo: Fix clock param realtime setting

2014-04-01 Thread Olivier Langlois 
Hi Laurent,

On Tue, 2014-04-01 at 15:49 +0200, Laurent Pinchart wrote:
 Hi Olivier,
 
 On Sunday 30 March 2014 00:23:01 Olivier Langlois wrote:
  Hi Laurent,
  
Yes. ffmpeg uses wall clock time to create timestamps for audio packets
from ALSA device.
   
   OK. I suppose I shouldn't drop support for the realtime clock like I
   wanted to then :-)
   
There is a bug in ffmpeg describing problems to synchronize audio and
the video from a v4l2 webcam.

https://trac.ffmpeg.org/ticket/692

To workaround this issue, ffmpeg devs added a switch to convert back

monotonic to realtime. From ffmpeg/libavdevice/v4l2.c:
  -tsint.D set type of timestamps for
 grabbed frames (from 0 to 2)
 (default 0)
 default  .D use timestamps from the kernel
 abs  .D use absolute timestamps (wall
 clock)
 mono2abs .D force conversion from monotonic
 to absolute timestamps

If the v4l2 driver is able to send realtime ts, it is easier synchronize
in userspace if all inputs use the same clock.
   
   That might be a stupid question, but shouldn't ALSA use the monotonic
   clock instead ?
  
  I think that I have that answer why ffmpeg use realtime clock for ALSA data.
  In fact ffmpeg uses realtime clock for every data coming from capture
  devices and the purpose is to be able to seek into the recorded stream by
  using the date where the recording occured. Same principle than a camera
  recording dates when pictures are taken.
 
  now a tougher question is whether or not it is up to the driver to provide
  these realtime ts.
 
 It makes sense to associate a wall time with recorded streams for that 
 purpose, but synchronization should in my opinion be performed using the 
 monotonic clock, as the wall time can jump around. I believe drivers should 
 provide monotonic timestamps only. However, given that the uvcvideo driver 
 has 
 the option of providing wall clock timestamps, that option should work, so 
 your patch makes sense. I'd still like to remove support for the wall clock 
 though, but I don't want to break userspace. ffmpeg should be fixed, 
 especially given that most V4L devices provide monotonic timestamps only.
 
Please do not stop yourself to remove realtime ts support in your driver
because that would not break ffmpeg, IMHO. It is just me that have tried
to leverage options offered by your driver to remove the need to use
ffmpeg workaround for a sync issue. I apparently have been the first
ffmpeg user to try out!

I am currently in the process to contribute the introduction of using
CLOCK_MONOTONIC inside ffmpeg. CCing their list because I think your
reply is relevant to the discussion we have on the topic there at the
moment.

thank you,
Olivier


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