[REVIEWv2 PATCH 37/34] v4l2-ctrls: set elem_size for all types handled by std_type_ops

2014-02-15 Thread Hans Verkuil
It makes sense to have elem_size prefilled for types that the control framework knows about. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/v4l2-core/v4l2-ctrls.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git

[REVIEWv2 PATCH 38/34] solo/go7007: drop elem_size: now set by control framework

2014-02-15 Thread Hans Verkuil
The control framework will fill in elem_size for the standard types the framework knows about, so no longer set these explicitly. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/staging/media/go7007/go7007-v4l2.c | 1 - drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c |

[REVIEWv2 PATCH 39/34] v4l2-ctrls: allow HIDDEN controls in the user class

2014-02-15 Thread Hans Verkuil
Previously hidden controls were not allowed in the user class due to backwards compatibility reasons (QUERYCTRL should not see them), but by simply testing if QUERYCTRL found a hidden control and returning -EINVAL this limitation can be lifted. Signed-off-by: Hans Verkuil hans.verk...@cisco.com

[REVIEWv2 PATCH 40/34] solo6x10: check dma_map_sg() return value

2014-02-15 Thread Hans Verkuil
The dma_map_sg() function can fail, so check for the return value. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[PATCH] staging: davinci_vpfe: fix error check

2014-02-15 Thread Levente Kurusa
The check would check the pointer, which is never less than 0. According to the error message, the correct check would be to check the return value of ipipe_mode. Check that instead. Reported-by: David Binderman dcb...@hotmail.com Signed-off-by: Levente Kurusa le...@linux.com ---

[PATCH] media: dvb-frontends/stb6100.c: Fix buffer length check

2014-02-15 Thread Alexander Shiyan
Signed-off-by: Alexander Shiyan shc_w...@mail.ru --- drivers/media/dvb-frontends/stb6100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/stb6100.c b/drivers/media/dvb-frontends/stb6100.c index cea175d..4ef8a5c 100644 ---

Re: [PATCH] staging: davinci_vpfe: fix error check

2014-02-15 Thread Josh Triplett
On Sat, Feb 15, 2014 at 11:17:11AM +0100, Levente Kurusa wrote: The check would check the pointer, which is never less than 0. According to the error message, the correct check would be to check the return value of ipipe_mode. Check that instead. Reported-by: David Binderman

linuxtv wiki: How to update device information?

2014-02-15 Thread Felix Schwarz
Hey, I tried to update some device information in the linuxtv wiki but failed (even though I'm logged in). For example the data table on http://www.linuxtv.org/wiki/index.php/Elgato_EyeTV_DTT_deluxe_v2 has an edit link in the rightmost cell but that redirects to

[PATCH v5 3/7] v4l: Add timestamp source flags, mask and document them

2014-02-15 Thread Sakari Ailus
Some devices do not produce timestamps that correspond to the end of the frame. The user space should be informed on the matter. This patch achieves that by adding buffer flags (and a mask) for timestamp sources since more possible timestamping points are expected than just two. A three-bit mask

[PATCH v5 7/7] v4l: Document timestamp buffer flag behaviour

2014-02-15 Thread Sakari Ailus
Timestamp buffer flags are constant at the moment. Document them so that 1) they're always valid and 2) not changed by the drivers. This leaves room to extend the functionality later on if needed. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/io.xml | 10

[PATCH v5 4/7] uvcvideo: Tell the user space we're using start-of-exposure timestamps

2014-02-15 Thread Sakari Ailus
The UVC device provided timestamps are taken from the clock once the exposure of the frame has begun, not when the reception of the frame would have been finished as almost anywhere else. Show this to the user space by using V4L2_BUF_FLAG_TSTAMP_SRC_SOE buffer flag. Signed-off-by: Sakari Ailus

[PATCH v5 6/7] v4l: Copy timestamp source flags to destination on m2m devices

2014-02-15 Thread Sakari Ailus
Copy the flags containing the timestamp source from source buffer flags to the destination buffer flags on memory-to-memory devices. This is analogous to copying the timestamp field from source to destination. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/media/platform/coda.c

[PATCH v5 1/7] v4l: Document timestamp behaviour to correspond to reality

2014-02-15 Thread Sakari Ailus
Document that monotonic timestamps are taken after the corresponding frame has been received, not when the reception has begun. This corresponds to the reality of current drivers: the timestamp is naturally taken when the hardware triggers an interrupt to tell the driver to handle the received

[PATCH v5 5/7] exynos-gsc, m2m-deinterlace, mx2_emmaprp: Copy v4l2_buffer data from src to dst

2014-02-15 Thread Sakari Ailus
The timestamp and timecode fields were copied from destination to source, not the other way around as they should. Fix it. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/media/platform/exynos-gsc/gsc-m2m.c |4 ++-- drivers/media/platform/m2m-deinterlace.c|4 ++--

Re: [PATCH v5 7/7] v4l: Document timestamp buffer flag behaviour

2014-02-15 Thread Hans Verkuil
On 02/15/2014 09:53 PM, Sakari Ailus wrote: Timestamp buffer flags are constant at the moment. Document them so that 1) they're always valid and 2) not changed by the drivers. This leaves room to extend the functionality later on if needed. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi

cron job: media_tree daily build: WARNINGS

2014-02-15 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: Sun Feb 16 04:00:29 CET 2014 git branch: test git hash: 37e59f876bc710d67a30b660826a5e83e07101ce gcc