Re: AW: AW: v4l2_buffer with PBO mapped memory

Hi Laurent, On 07.04.2014 01:37, Laurent Pinchart wrote: Hi Thomas, On Friday 04 April 2014 20:01:33 Scheuermann, Mail wrote: Hi Laurent, I've done the following: echo 3 >/sys/module/videobuf2_core/parameters/debug and found in /var/log/kern.log after starting my program: [239432.535077] v

Re: [v2] media: soc-camera: OF cameras

Hi, Guennadi On 4/11/2014 5:18 AM, Guennadi Liakhovetski wrote: Hi Bryan, On Tue, 8 Apr 2014, Bryan Wu wrote: Thanks Josh, I think I will take you point and rework my patch again. But I need Guennadi's review firstly, Guennadi, could you please help to review it? Ok, let me double check the

cron job: media_tree daily build: OK

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: Fri Apr 11 04:00:16 CEST 2014 git branch: test git hash: a83b93a7480441a47856dc9104bea970e84cda87 gcc versi

Re: [PATCH 4/6] v4l: vsp1: Add DT support

On Fri, Apr 11, 2014 at 01:37:11AM +0200, Laurent Pinchart wrote: > Hi Simon, > > On Friday 11 April 2014 08:04:18 Simon Horman wrote: > > On Tue, Mar 25, 2014 at 01:18:22PM +0100, Laurent Pinchart wrote: > > > Hello, > > > > > > Gentle ping. I'll send a pull request in a week if I don't receive

Re: [PATCH 4/6] v4l: vsp1: Add DT support

Hi Simon, On Friday 11 April 2014 08:04:18 Simon Horman wrote: > On Tue, Mar 25, 2014 at 01:18:22PM +0100, Laurent Pinchart wrote: > > Hello, > > > > Gentle ping. I'll send a pull request in a week if I don't receive any > > comment on the DT bindings in the meantime. > > Hi Laurent, > > one wa

Re: [PATCH 4/6] v4l: vsp1: Add DT support

On Tue, Mar 25, 2014 at 01:18:22PM +0100, Laurent Pinchart wrote: > Hello, > > Gentle ping. I'll send a pull request in a week if I don't receive any > comment > on the DT bindings in the meantime. Hi Laurent, one way or another can you let me know if/when the bindings are accepted and I'll qu

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

Laurent Pinchart wrote: On Thursday 10 April 2014 21:58:41 Sakari Ailus wrote: Laurent Pinchart wrote: 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 ? When processing

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

Hi Laurent, Laurent Pinchart wrote: Just thinking out loud, we need to - initialize the device structure, - open the device or use an externally provided fd, - optionally query the device capabilities, - optionally override the queue type. Initializing the device structure must be performed un

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

On Thursday 10 April 2014 21:58:41 Sakari Ailus wrote: > Laurent Pinchart wrote: > > 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 ? > > When processing

Re: [PATCH v2 1/9] Provide -Q option for setting the queue type

Hi, Sakari Ailus wrote: Instead of guessing the queue type, allow setting it explicitly. These got out a little bit too fast... what would you expect git send-email to do if you press ^C? Changes since v1: - Replace --output (-o, for which getopt handling was actually missing) option with

Re: [RFC] Helper to abstract vma handling in media layer

On Thu 10-04-14 23:57:38, Jan Kara wrote: > On Thu 10-04-14 14:22:20, Hans Verkuil wrote: > > On 04/10/14 14:15, Jan Kara wrote: > > > On Thu 10-04-14 13:07:42, Hans Verkuil wrote: > > >> On 04/10/14 12:32, Jan Kara wrote: > > >>> Hello, > > >>> > > >>> On Thu 10-04-14 12:02:50, Marek Szyprowski

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

Hi Sakari, On Thursday 10 April 2014 21:48:55 Sakari Ailus wrote: > Hi Laurent, > > Thanks for the comments. > > Laurent Pinchart wrote: > ... > > >> @@ -196,6 +192,16 @@ static int video_open(struct device *dev, const char > >> *devname, int no_query) > >> > >>printf("Device %s opened.\n"

[PATCH v2 2/9] Zero dev in main()

This is necessary since video_open() may not be always called soon Signed-off-by: Sakari Ailus --- yavta.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/yavta.c b/yavta.c index d7bccfd..18e1709 100644 --- a/yavta.c +++ b/yavta.c @@ -226,7 +226,6 @@ static int video_ope

[PATCH v2 7/9] Print timestamp type and source for dequeued buffers

Signed-off-by: Sakari Ailus --- yavta.c | 52 ++-- 1 file changed, 30 insertions(+), 22 deletions(-) diff --git a/yavta.c b/yavta.c index a2e0666..9810dcf 100644 --- a/yavta.c +++ b/yavta.c @@ -659,6 +659,30 @@ static void video_buffer_fill_userp

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

Signed-off-by: Sakari Ailus --- yavta.c | 46 +++--- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/yavta.c b/yavta.c index 12a6719..6f80311 100644 --- a/yavta.c +++ b/yavta.c @@ -63,6 +63,7 @@ struct buffer struct device { int

[PATCH v2 8/9] Support copy timestamps

Signed-off-by: Sakari Ailus --- yavta.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/yavta.c b/yavta.c index 9810dcf..124dd1d 100644 --- a/yavta.c +++ b/yavta.c @@ -668,6 +668,9 @@ static void get_ts_flags(uint32_t flags, const char **ts_type, const char **ts_s case V4L2_BUF

[PATCH v2 4/9] Separate querying capabilities and determining buffer queue type

Signed-off-by: Sakari Ailus --- yavta.c | 78 ++- 1 file changed, 42 insertions(+), 36 deletions(-) diff --git a/yavta.c b/yavta.c index 5a35bab..12a6719 100644 --- a/yavta.c +++ b/yavta.c @@ -220,12 +220,8 @@ static const char *v4l2_

[PATCH v2 9/9] Set timestamp for output buffers if the timestamp type is copy

Copy timestamp type will mean the timestamp is be copied from the source to the destination buffer on mem-to-mem devices. Signed-off-by: Sakari Ailus --- yavta.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/yavta.c b/yavta.c index 124dd1d..251fe40 100644 ---

[PATCH v2 3/9] Use int for buffer queue type

This makes comparisons nicer. Signed-off-by: Sakari Ailus --- yavta.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yavta.c b/yavta.c index 18e1709..5a35bab 100644 --- a/yavta.c +++ b/yavta.c @@ -64,7 +64,7 @@ struct device { int fd; - enum v4l2_buf_type

[PATCH v2 1/9] Provide -Q option for setting the queue type

Instead of guessing the queue type, allow setting it explicitly. Signed-off-by: Sakari Ailus --- yavta.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/yavta.c b/yavta.c index 739463d..d7bccfd 100644 --- a/yavta.c +++ b/yavta.c @@ -1501,6 +1501,8 @@ sta

[PATCH v2 6/9] Timestamp source for output buffers

Signed-off-by: Sakari Ailus --- yavta.c | 17 + 1 file changed, 17 insertions(+) diff --git a/yavta.c b/yavta.c index 6f80311..a2e0666 100644 --- a/yavta.c +++ b/yavta.c @@ -72,6 +72,7 @@ struct device unsigned int width; unsigned int height; + uint32_t

Re: [RFC] Helper to abstract vma handling in media layer

On Thu 10-04-14 14:22:20, Hans Verkuil wrote: > On 04/10/14 14:15, Jan Kara wrote: > > On Thu 10-04-14 13:07:42, Hans Verkuil wrote: > >> On 04/10/14 12:32, Jan Kara wrote: > >>> Hello, > >>> > >>> On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: > On 2014-03-17 20:49, Jan Kara wrote: > >>>

Re: [PATCH 41/49] rc-core: rename mutex

On Friday 04 April 2014 01:34:43 David Härdeman wrote: > Having a mutex named "lock" is a bit misleading. Why? A mutex is a type of lock so what's the problem? A little grep'ing and sed'ing reveals that out of the 1578 unique mutex names in the kernel source I have to hand, 540 contain "lock", a

Re: [v2] media: soc-camera: OF cameras

Hi Bryan, On Tue, 8 Apr 2014, Bryan Wu wrote: > Thanks Josh, I think I will take you point and rework my patch again. > But I need Guennadi's review firstly, Guennadi, could you please help > to review it? Ok, let me double check the situation: 1. We've got this patch from you, aiming at adding

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

Hi Laurent, Laurent Pinchart wrote: 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 ? When processing frames from memory to memory (COPY timestamp type), the it is entir

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

Hi Laurent, Laurent Pinchart wrote: ... @@ -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_TS

[GIT PULL FOR v3.16] VSP1 fixes and features

Hi Mauro, The following changes since commit a83b93a7480441a47856dc9104bea970e84cda87: [media] em28xx-dvb: fix PCTV 461e tuner I2C binding (2014-03-31 08:02:16 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git vsp1/next for you to fetch changes up to 3d9

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

Hi Laurent, Thanks for the comments. Laurent Pinchart wrote: ... @@ -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(struc

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

Laurent Pinchart wrote: 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 outp

Re: Hauppauge ImpactVCB-e 01385

Hi Steve, > Well not nobody because I do. How do I do it? If you would guide me through, > I will happily update it. I seem to recall Kernel Labs offered you some commercial help with this product in the past and you declined, you apparently wanted to tackle it on your own. How's it coming alon

Re: Hauppauge ImpactVCB-e 01385

>The issue is nobody cares enough to >update the driver to support >your card and make it work out of the box. Hi Steve, Thanks for your response. Well not nobody because I do. How do I do it? If you would guide me through, I will happily update it. Regards Steve. Steven Toth wrote: >> W

Re: Hauppauge ImpactVCB-e 01385

> When I plug in my 01385 I get the same old stuff in dmseg, ie: > > cx23885 driver version 0.0.3 loaded > [ 8.921390] cx23885[0]: Your board isn't known (yet) to the driver. > [ 8.921390] cx23885[0]: Try to pick one of the existing card configs via > [ 8.921390] cx23885[0]: card= insmod option. Up

[PATCH 2/2] [RFC v2 with seqcount] reservation: add suppport for read-only access using rcu

op 10-04-14 13:08, Thomas Hellstrom schreef: On 04/10/2014 12:07 PM, Maarten Lankhorst wrote: Hey, op 10-04-14 10:46, Thomas Hellstrom schreef: Hi! Ugh. This became more complicated than I thought, but I'm OK with moving TTM over to fence while we sort out how / if we're going to use this. W

Re: [RFC PATCH 0/2] managed token devres interfaces

Em Thu, 10 Apr 2014 12:46:53 +0100 One Thousand Gnomes escreveu: > > For example, some devices provide standard USB Audio Class, handled by > > snd-usb-audio for the audio stream, while the video stream is handled > > via a separate driver, like some em28xx devices. > > Which is what mfd is desi

Re: [RFC PATCH 0/2] managed token devres interfaces

On 04/10/2014 05:38 AM, Mauro Carvalho Chehab wrote: Hi Alan, Em Thu, 10 Apr 2014 12:04:35 +0100 One Thousand Gnomes escreveu: - Construct string with (dev is struct em28xx *dev) format: "tuner:%s-%s-%d" with the following: dev_name(&dev-

Re: [PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

On Thu, Apr 10, 2014 at 09:57:23PM +1000, Vitaly Osipov wrote: > Thanks, that's helpful - I for some reason thought that multi-part > patch had to have more or less uniform subject. We the checkpatch.pl > people come from http://www.eudyptula-challenge.org/, where at some > stage we are told to sub

Re: [RFC] Helper to abstract vma handling in media layer

On 04/10/14 14:15, Jan Kara wrote: > On Thu 10-04-14 13:07:42, Hans Verkuil wrote: >> On 04/10/14 12:32, Jan Kara wrote: >>> Hello, >>> >>> On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: On 2014-03-17 20:49, Jan Kara wrote: > The following patch series is my first stab at abstractin

Re: [RFC] Helper to abstract vma handling in media layer

On Thu 10-04-14 13:07:42, Hans Verkuil wrote: > On 04/10/14 12:32, Jan Kara wrote: > > Hello, > > > > On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: > >> On 2014-03-17 20:49, Jan Kara wrote: > >>> The following patch series is my first stab at abstracting vma handling > >> >from the various

[GIT PULL 3.15] rtl2832_sdr attach fixes

The following changes since commit a83b93a7480441a47856dc9104bea970e84cda87: [media] em28xx-dvb: fix PCTV 461e tuner I2C binding (2014-03-31 08:02:16 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git fixes3.15_rtl2832_sdr_attach for you to fetch chang

Re: [PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

Thanks, that's helpful - I for some reason thought that multi-part patch had to have more or less uniform subject. We the checkpatch.pl people come from http://www.eudyptula-challenge.org/, where at some stage we are told to submit a patch for a single style issue in the staging tree. All newbies..

Re: [RFC PATCH 0/2] managed token devres interfaces

> For example, some devices provide standard USB Audio Class, handled by > snd-usb-audio for the audio stream, while the video stream is handled > via a separate driver, like some em28xx devices. Which is what mfd is designed to handle. > There are even more complex devices that provide 3G modem,

Re: [RFC PATCH 0/2] managed token devres interfaces

Hi Alan, Em Thu, 10 Apr 2014 12:04:35 +0100 One Thousand Gnomes escreveu: > > >> - Construct string with (dev is struct em28xx *dev) > > >> format: "tuner:%s-%s-%d" > > >> with the following: > > >> dev_name(&dev->udev->dev) > > >> dev->u

Re: [PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu

On 04/10/2014 01:08 PM, Thomas Hellstrom wrote: > On 04/10/2014 12:07 PM, Maarten Lankhorst wrote: >> Hey, >> >> op 10-04-14 10:46, Thomas Hellstrom schreef: >>> Hi! >>> >>> Ugh. This became more complicated than I thought, but I'm OK with moving >>> TTM over to fence while we sort out >>> how / if

Re: [RFC] Helper to abstract vma handling in media layer

On 04/10/14 12:32, Jan Kara wrote: > Hello, > > On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: >> On 2014-03-17 20:49, Jan Kara wrote: >>> The following patch series is my first stab at abstracting vma handling >> >from the various media drivers. After this patch set drivers have to know >>

Re: [PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu

On 04/10/2014 12:07 PM, Maarten Lankhorst wrote: > Hey, > > op 10-04-14 10:46, Thomas Hellstrom schreef: >> Hi! >> >> Ugh. This became more complicated than I thought, but I'm OK with moving >> TTM over to fence while we sort out >> how / if we're going to use this. >> >> While reviewing, it struck

Re: [RFC PATCH 0/2] managed token devres interfaces

> >> - Construct string with (dev is struct em28xx *dev) > >>format: "tuner:%s-%s-%d" > >>with the following: > >>dev_name(&dev->udev->dev) > >> dev->udev->bus->bus_name > >> dev->tuner_addr What guarantees this wo

Hauppauge ImpactVCB-e 01385

Hi Guys, Sorry to go on about the Hauppauge ImpactVCB-e 01385, but it's a couple of years and version 12.04, since I last asked. This page: http://linuxtv.org/wiki/index.php/Hauppauge Now shows: Table of analog-only devices sold by Hauppauge Model Standard Interface Supported Comments Impa

Re: [RFC] Helper to abstract vma handling in media layer

Hello, On Thu 10-04-14 12:02:50, Marek Szyprowski wrote: > On 2014-03-17 20:49, Jan Kara wrote: > > The following patch series is my first stab at abstracting vma handling > >from the various media drivers. After this patch set drivers have to know > >much less details about vmas, their types,

Re: [PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu

Hey, op 10-04-14 10:46, Thomas Hellstrom schreef: Hi! Ugh. This became more complicated than I thought, but I'm OK with moving TTM over to fence while we sort out how / if we're going to use this. While reviewing, it struck me that this is kind of error-prone, and hard to follow since we're op

Re: [RFC] Helper to abstract vma handling in media layer

Hello, On 2014-03-17 20:49, Jan Kara wrote: The following patch series is my first stab at abstracting vma handling from the various media drivers. After this patch set drivers have to know much less details about vmas, their types, and locking. My motivation for the series is that I want to

Re: [PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

The two subjects are really close to being the same. You should choose better subjects. Like: [PATCH 2/2] staging: media: omap24xx: use pr_info() instead of KERN_INFO (All the checkpatch.pl people use the exact same subject for everything though, so you're not alone in this). regards, dan car

[PATCH 2/2] staging: media: omap24xx: fix up a checkpatch.pl warning

tcm825x.c: changed printk to pr_info Signed-off-by: Vitaly Osipov --- drivers/staging/media/omap24xx/tcm825x.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/omap24xx/tcm825x.c b/drivers/staging/media/omap24xx/tcm825x.c index 2326481..3367ccd 1

[PATCH 1/2] staging: media: omap24xx: fix up checkpatch error message

tcm825x.c and tcm825x.h: fixing ERROR: Macros with complex values should be enclosed in parenthesis Signed-off-by: Vitaly Osipov --- drivers/staging/media/omap24xx/tcm825x.c |8 drivers/staging/media/omap24xx/tcm825x.h |4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)

Re: [PATCH 2/2] [RFC] reservation: add suppport for read-only access using rcu

Hi! Ugh. This became more complicated than I thought, but I'm OK with moving TTM over to fence while we sort out how / if we're going to use this. While reviewing, it struck me that this is kind of error-prone, and hard to follow since we're operating on a structure that may be continually update

Re: [PATCH 2/2] dma-buf: update exp_name when using dma_buf_export()

On Thu, Apr 10, 2014 at 01:30:06AM +0200, Javier Martinez Canillas wrote: > commit c0b00a5 ("dma-buf: update debugfs output") modified the > default exporter name to be the KBUILD_MODNAME pre-processor > macro instead of __FILE__ but the documentation was not updated. > > Also the "Supporting exis

[PATCH v2 4/8] s5p-jpeg: Fix build break when CONFIG_OF is undefined

This patch fixes build break occurring when there is no support for Device Tree turned on in the kernel configuration. In such a case only the driver variant for S5PC210 SoC will be available. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park --- drivers/media/platform/s5p-jpeg/jpeg-

[PATCH v2 8/8] s5p_jpeg: Fix NV12 format entry related to S5C2120 SoC

S5PC210 SoC doesn't support encoding NV12 raw images. Remove the relavant flag from the respective entry in the sjpeg_formats array. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park --- drivers/media/platform/s5p-jpeg/jpeg-core.c |3 +-- 1 file changed, 1 insertion(+), 2 deletio

[PATCH v2 2/8] s5p-jpeg: Perform fourcc downgrade only for Exynos4x12 SoCs

Change the driver variant check from "is not S5PC210" to "is Exynos4" while checking whether YUV format needs to be downgraded in order to prevent upsampling which is not supported by Exynos4 SoCs family. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park --- drivers/media/platform/s5

[PATCH v2 3/8] s5p-jpeg: Add m2m_ops field to the s5p_jpeg_variant structure

Simplify the code by adding m2m_ops field to the s5p_jpeg_variant structure which allows to avoid "if" statement in the s5p_jpeg_probe function. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 12 drivers/media/platfo

[PATCH v2 1/8] s5p-jpeg: Add fmt_ver_flag field to the s5p_jpeg_variant structure

Simplify the code by adding fmt_ver_flag field to the s5p_jpeg_variant structure which allows to avoid "if" statement in the s5p_jpeg_find_format function. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 11 --- drivers/me

[PATCH v2 5/8] s5p-jpeg: g_selection callback should always succeed

Remove erroneous guard preventing successful execution of g_selection callback in case the driver variant is different from SJPEG_S5P. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park --- drivers/media/platform/s5p-jpeg/jpeg-core.c |3 +-- 1 file changed, 1 insertion(+), 2 delet

[PATCH v2 7/8] s5p_jpeg: Prevent JPEG 4:2:0 > YUV 4:2:0 decompression

Prevent decompression of a JPEG 4:2:0 with odd width to the YUV 4:2:0 compliant formats for Exynos4x12 SoCs and adjust capture format to RGB565 in such a case. This is required because the configuration would produce a raw image with broken luma component. Signed-off-by: Jacek Anaszewski Signed-o

[PATCH v2 6/8] s5p-jpeg: Fix sysmmu page fault

This patch fixes jpeg sysmmu page fault on Exynos4x12 SoCs. During encoding Exynos4x12 SoCs access wider memory area than it results from Image_x and Image_y values written to the JPEG_IMAGE_SIZE register. In order to avoid sysmmu page fault apply proper output buffer size alignment. Signed-off-by