uvcvideo: Dropping payload (out of sync)

2013-04-10 Thread André Weidemann

Hi,

I ran into a problem while trying to get a Microsoft LifeCam 
Studio(TM) (045e:0772) to work with uvccapture on a Raspberry PI 
running Kernel 3.6.11 under Debian Wheezy.


I started grabbing a picture with:
/usr/bin/uvccapture -x1920 -y1080 -o/media/ramdisk/webcam.jpg -q80

[1] 
http://ftp.de.debian.org/debian/pool/main/u/uvccapture/uvccapture_0.5.orig.tar.gz
[2] 
http://ftp.de.debian.org/debian/pool/main/u/uvccapture/uvccapture_0.5-2.debian.tar.gz


Grabbing a picture takes between 20 seconds and 1-2 minutes. 
Unfortuantely the captured image is heavily distorted.


Doing a stack trace I see that it always hangs on:

ioctl(3, VIDIOC_STREAMON, 0xbe8f15e4)   = 0
ioctl(3, VIDIOC_DQBUF

So I did an:
echo 0x  /sys/module/uvcvideo/parameters/trace

This resulted in a rather lengthy kernel log starting like this:

Apr 10 07:08:11 raspberrypi kernel: [ 5262.503209] uvcvideo: 
uvc_v4l2_ioctl(VIDIOC_G_CTRL)
Apr 10 07:08:11 raspberrypi kernel: [ 5262.509395] uvcvideo: 
uvc_v4l2_ioctl(VIDIOC_QUERYCTRL)
Apr 10 07:08:11 raspberrypi kernel: [ 5262.509466] uvcvideo: Control 
0x00980913 not found.
Apr 10 07:08:11 raspberrypi kernel: [ 5262.519683] uvcvideo: 
uvc_v4l2_ioctl(VIDIOC_STREAMON)
Apr 10 07:08:11 raspberrypi kernel: [ 5262.524446] uvcvideo: Device 
requested 3072 B/frame bandwidth.
Apr 10 07:08:11 raspberrypi kernel: [ 5262.524481] uvcvideo: Selecting 
alternate setting 24 (3072 B/frame bandwidth).
Apr 10 07:08:11 raspberrypi kernel: [ 5262.534925] uvcvideo: Allocated 5 
URB buffers of 32x3072 bytes each.
Apr 10 07:08:11 raspberrypi kernel: [ 5262.540632] uvcvideo: 
uvc_v4l2_ioctl(VIDIOC_DQBUF)
Apr 10 07:08:12 raspberrypi kernel: [ 5263.014155] uvcvideo: USB 
isochronous frame lost (-63).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.019468] uvcvideo: USB 
isochronous frame lost (-63).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.024473] uvcvideo: USB 
isochronous frame lost (-63).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.068612] uvcvideo: USB 
isochronous frame lost (-63).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.078582] uvcvideo: USB 
isochronous frame lost (-63).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.327576] uvcvideo: USB 
isochronous frame lost (-63).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.366721] uvcvideo: Frame 
complete (overflow).
Apr 10 07:08:12 raspberrypi kernel: [ 5263.366759] uvcvideo: Dropping 
payload (out of sync).


It continued to show over 1Mio lines in 5 minutes with:
Apr 10 07:08:12 raspberrypi kernel: [ 5263.371102] uvcvideo: Dropping 
payload (out of sync).


intermitted by a few:
Apr 10 07:08:12 raspberrypi kernel: [ 5263.388864] uvcvideo: USB 
isochronous frame lost (-63).
After enabling the trace uvccapture was not able to garb an image at 
all. I had to kill the process.


I am at loss here... The whole setup worked flawlessly on my Laptop with 
Debian Wheezy and kernel 3.2 on an Intel Chipset.


I did a few more tests lowering the capture resolution which seemed to 
work a lot better. Up to 800x600 the images were captured almost 
instantly, but they were still distorted. At the resolution of 640x480 
the images were finally clear. But since the camera supports 1920x1080, 
I would also like to be able to capture at this resolution...


Any help is greatly appreciated.

Thanks in advance.
 André
--
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] v4l2-ctl: break down the streaming_set()

2013-04-10 Thread Hans Verkuil
On Wed April 10 2013 07:35:34 Tzu-Jung Lee wrote:
 This patch breaks down the streaming_set() into smaller
 ones, which can be resued for supporting m2m devices.
 
 Further cleanup or consolidation can be applied with
 separate patches, since this one tries not to modify
 logics.
 ---
  utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 888 
 ++
  1 file changed, 480 insertions(+), 408 deletions(-)
 

Thanks! This looks very nice. I knew this code had to be cleaned up at some
point :-)

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/2] v4l2-ctl: break down the streaming_set()

2013-04-10 Thread Hans Verkuil
On Wed April 10 2013 07:35:34 Tzu-Jung Lee wrote:
 This patch breaks down the streaming_set() into smaller
 ones, which can be resued for supporting m2m devices.
 
 Further cleanup or consolidation can be applied with
 separate patches, since this one tries not to modify
 logics.
 ---
  utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 888 
 ++
  1 file changed, 480 insertions(+), 408 deletions(-)
 
 diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp 
 b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 index c29565f..f8e782d 100644
 --- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 +++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 @@ -27,7 +27,8 @@ static unsigned stream_skip;
  static unsigned stream_pat;
  static bool stream_loop;
  static unsigned reqbufs_count = 3;
 -static char *file;
 +static char *file_cap;
 +static char *file_out;
  
  #define NUM_PATTERNS (4)
  
 @@ -198,12 +199,12 @@ void streaming_cmd(int ch, char *optarg)
   stream_pat %= NUM_PATTERNS;
   break;
   case OptStreamTo:
 - file = optarg;
 - if (!strcmp(file, -))
 + file_cap = optarg;
 + if (!strcmp(file_cap, -))
   options[OptSilent] = true;
   break;
   case OptStreamFrom:
 - file = optarg;
 + file_out = optarg;
   break;
   case OptStreamMmap:
   case OptStreamUser:
 @@ -526,475 +527,546 @@ static bool fill_buffer_from_file(void *buffers[], 
 unsigned buffer_lengths[],
   return true;
  }
  
 -void streaming_set(int fd)
 +static void do_setup_cap_buffers(int fd, struct v4l2_requestbuffers *reqbufs,
 +  bool is_mplane, unsigned num_planes, bool 
 is_mmap,

num_planes should be a reference: 'unsigned num_planes'. This function changes
num_planes and the caller needs that! Ditto for do_setup_out_buffers.

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 2/2] v4l2-ctl: initial attempt to support M2M device streaming

2013-04-10 Thread Hans Verkuil
On Wed April 10 2013 07:35:35 Tzu-Jung Lee wrote:
 ---
  utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 189 
 +-
  1 file changed, 188 insertions(+), 1 deletion(-)
 
 diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp 
 b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 index f8e782d..b86c467 100644
 --- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 +++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 @@ -1058,12 +1058,199 @@ void streaming_set_out(int fd)
   fclose(fin);
  }
  
 +enum stream_type {
 + CAP,
 + OUT,
 +};
 +
 +void streaming_set_m2m(int fd)
 +{
 + int fd_flags = fcntl(fd, F_GETFL);
 + bool use_poll = options[OptStreamPoll];
 +
 + bool is_mplane = capabilities 
 + (V4L2_CAP_VIDEO_CAPTURE_MPLANE |
 +  V4L2_CAP_VIDEO_OUTPUT_MPLANE |
 +  V4L2_CAP_VIDEO_M2M_MPLANE);

This should only check for V4L2_CAP_VIDEO_M2M_MPLANE. Only if that is set is M2M
valid. I think it is probably a good idea to add some capability checks to each
streaming_set_*() function checking up front whether the device supports that
particular streaming option.

 + unsigned num_planes = 1;

num_planes may differ between capture and output, so this should be 
num_planes[2] = { 1, 1 }

 + bool is_mmap = options[OptStreamMmap];
 +
 + __u32 type[2];
 + FILE *file[2] = {NULL, NULL};
 + struct v4l2_requestbuffers reqbufs[2];
 +
 + type[CAP] = is_mplane ?
 + V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE : 
 V4L2_BUF_TYPE_VIDEO_CAPTURE;
 +
 + type[OUT] = is_mplane ?
 + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE : V4L2_BUF_TYPE_VIDEO_OUTPUT;
 +
 + memset(reqbufs, 0, sizeof(reqbufs));
 +
 + reqbufs[CAP].count = reqbufs_count;

Capture and output can have different reqbufs_count values. That static needs 
to be
split up in a capture and output variant.

 + reqbufs[CAP].type = type[CAP];
 + reqbufs[CAP].memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
 +
 + reqbufs[OUT].count = reqbufs_count;
 + reqbufs[OUT].type = type[OUT];
 + reqbufs[OUT].memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
 +
 + struct v4l2_event_subscription sub;
 +
 + memset(sub, 0, sizeof(sub));
 + sub.type = V4L2_EVENT_EOS;
 + ioctl(fd, VIDIOC_SUBSCRIBE_EVENT, sub);
 +
 + if (file_cap) {
 + if (!strcmp(file_cap, -))
 + file[CAP] = stdout;
 + else
 + file[CAP] = fopen(file_cap, w+);
 + }
 +
 + if (file_out) {
 + if (!strcmp(file_out, -))
 + file[OUT] = stdin;
 + else
 + file[OUT] = fopen(file_out, r);
 + }
 +
 + if (doioctl(fd, VIDIOC_REQBUFS, reqbufs[CAP]) ||
 + doioctl(fd, VIDIOC_REQBUFS, reqbufs[OUT]))
 + return;
 +
 + void *buffers[2][reqbufs_count * VIDEO_MAX_PLANES];
 + unsigned buffer_lengths[2][reqbufs_count * VIDEO_MAX_PLANES];
 +
 + do_setup_cap_buffers(fd, reqbufs[CAP], is_mplane, num_planes,
 +  is_mmap, buffers[CAP], buffer_lengths[CAP]);
 +
 + do_setup_out_buffers(fd, reqbufs[OUT], is_mplane, num_planes,
 +  is_mmap, buffers[OUT], buffer_lengths[OUT],
 +  file[OUT]);
 +
 + if (doioctl(fd, VIDIOC_STREAMON, type[CAP]) ||
 + doioctl(fd, VIDIOC_STREAMON, type[OUT]))
 + return;
 +
 + if (use_poll)
 + fcntl(fd, F_SETFL, fd_flags | O_NONBLOCK);
 +
 + unsigned count[2] = { 0, 0 };
 + unsigned last[2] = { 0, 0 };
 + struct timeval tv_last[2];
 + bool eos[2] = { false, false};

No. eos is valid for the capture only. There is no eos[OUT].

 + fd_set read_fds;
 + fd_set write_fds;
 + fd_set exception_fds;
 +
 + while (!eos[CAP] || !eos[OUT]) {
 +
 + int r;
 +
 + if (use_poll) {
 + struct timeval tv;
 +
 + FD_ZERO(read_fds);
 + FD_SET(fd, read_fds);
 +
 + FD_ZERO(write_fds);
 + FD_SET(fd, write_fds);
 +
 + FD_ZERO(exception_fds);
 + FD_SET(fd, exception_fds);
 +
 + /* Timeout. */
 + tv.tv_sec = 2;
 + tv.tv_usec = 0;
 +
 + r = select(fd + 1, read_fds, write_fds, 
 exception_fds, tv);
 +
 + if (r == -1) {
 + if (EINTR == errno)
 + continue;
 + fprintf(stderr, select error: %s\n,
 + strerror(errno));
 + return;
 + }
 +
 + if (r == 0) {
 + fprintf(stderr, select timeout\n);
 + return;
 + }
 + }
 +
 +

Re: [PATCH 1/2] v4l2-ctl: break down the streaming_set()

2013-04-10 Thread Hans Verkuil
On Wed April 10 2013 07:35:34 Tzu-Jung Lee wrote:
 This patch breaks down the streaming_set() into smaller
 ones, which can be resued for supporting m2m devices.
 
 Further cleanup or consolidation can be applied with
 separate patches, since this one tries not to modify
 logics.
 ---
  utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 888 
 ++
  1 file changed, 480 insertions(+), 408 deletions(-)

Can you also add a 'Signed-off-by' line for these patches? While this code
isn't kernel code I still think it would be nice to properly attribute these
changes to you.

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


v4l2-ctl-streaming: ideas for improvements

2013-04-10 Thread Hans Verkuil
Hi all,

Just in case someone has time to work on this: I thought I'd write down some
of the ideas I have to improve the streaming code in v4l2-ctl:

1) Add an option to select between limited and full range colors.

2) Add more test patterns:
- solid colors: black, white, red, green, blue, cyan, yellow, magenta.
- grey 'color' bar
- grey ramp
- a pattern containing SAV and EAV codes in each plane (perhaps this
  should be a separate option, 'overlaying' those codes): this is a very
  nasty test case that can be used to test proper handling of such codes
  in an image.
- moving patterns
- horizontal colorbars
- thin lines: horizontal, vertical, both.
- random contents

3) For the capture side add pattern validation: check that the contents you
   captured matches the given pattern. Very useful for testing.

4) Add support for capturing/displaying frames with different sizes (e.g.
   compressed streams). Currently the output just appends all planes/frames
   together without writing the plane/frame sizes anywhere. The input assumes
   fixed sized planes/frames. We probably need to add a meta file that contains
   the 'bytesused' values. Perhaps that file should also contain format
   information that can be used later.

5) Add some support to give keyboard commands when streaming. E.g. 'q' to stop
   streaming gracefully (and so also ensure that all the data is written to 
file,
   something that doesn't happen with ctrl-c).

   Other commands for the future are encoder/decoder commands such as speeding 
up
   or down.

6) MPEG encoders can generate an index file (VIDIOC_G_ENC_INDEX). Add an option 
to
   generate that and to use it when decoding. I actually have some old test
   application that does just that, and that also has encoder/decoder command
   support (see item 5 above): http://ivtvdriver.org/svn/ivtvtv

7) Add VBI streaming support. Split off the VBI code from qv4l2 into a library
   and use that in v4l2-ctl to slice the raw VBI and to interpret the data. That
   should replace the vbi-test.c, sliced-vbi-detect.c and sliced-vbi-test.c
   utilities in contrib.

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 v2 2/3] mutex: add support for reservation style locks, v2

2013-04-10 Thread Peter Zijlstra
On Tue, 2013-04-09 at 18:42 -0400, Steven Rostedt wrote:
 What about setting an age as soon as it starts the process
 of grabbing one of these locks? And it keeps the age until it
 successfully grabs and releases all the locks again. It wont reset if
 it
 had to drop the locks and start over.


That is indeed the proposed mechanism. It ensures FIFO fairness between
the various threads that try to acquire a set.

--
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 v2 2/3] mutex: add support for reservation style locks, v2

2013-04-10 Thread Daniel Vetter
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt rost...@goodmis.org wrote:
 On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
 On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
  Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
  wait
  times of older task.

 No, imagine the following:

 struct ww_mutex A, B;
 struct mutex C;

   task-O  task-Y  task-X
   A
   B
   C
   C
   B

 At this point O finds that Y owns B and thus we want to make Y 'yield'
 B to make allow B progress. Since Y is blocked, we'll send a wakeup.
 However Y is blocked on a different locking primitive; one that doesn't
 collaborate in the -EDEADLK scheme therefore we don't want the wakeup to
 succeed.

 I'm confused to why the above is a problem. Task-X will eventually
 release C, and then Y will release B and O will get to continue. Do we
 have to drop them once the owner is blocked? Can't we follow the chain
 like the PI code does?

Just waiting until every task already holding a lock completes and
unlucks it is indeed a viable solution - it's the currently
implemented algorithm in ttm and Maarten's current patches.

The nice thing with Peter's wakeup idea on top is:
- It bounds blocked times.
- And (at least I think so) it's the key thing making PI boosting
possible without any ugly PI inversion deadlocks happening. See

Message-ID: cakmk7ueudtiddcrpwpiumkrst6sufy7yuqcpaxr_nj0xhkz...@mail.gmail.com

for my current reasoning about this (I have not yet managed to poke a
hole into it).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 2/2] v4l2-ctl: initial attempt to support M2M device streaming

2013-04-10 Thread Tzu-Jung Lee
On Wed, Apr 10, 2013 at 2:48 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Wed April 10 2013 07:35:35 Tzu-Jung Lee wrote:
 ---
  utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 189 
 +-
  1 file changed, 188 insertions(+), 1 deletion(-)

 diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp 
 b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 index f8e782d..b86c467 100644
 --- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 +++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
 @@ -1058,12 +1058,199 @@ void streaming_set_out(int fd)
   fclose(fin);
  }

 +enum stream_type {
 + CAP,
 + OUT,
 +};
 +
 +void streaming_set_m2m(int fd)
 +{
 + int fd_flags = fcntl(fd, F_GETFL);
 + bool use_poll = options[OptStreamPoll];
 +
 + bool is_mplane = capabilities 
 + (V4L2_CAP_VIDEO_CAPTURE_MPLANE |
 +  V4L2_CAP_VIDEO_OUTPUT_MPLANE |
 +  V4L2_CAP_VIDEO_M2M_MPLANE);

 This should only check for V4L2_CAP_VIDEO_M2M_MPLANE. Only if that is set is 
 M2M
 valid. I think it is probably a good idea to add some capability checks to 
 each
 streaming_set_*() function checking up front whether the device supports that
 particular streaming option.

 + unsigned num_planes = 1;

 num_planes may differ between capture and output, so this should be 
 num_planes[2] = { 1, 1 }


Sure.

 + bool is_mmap = options[OptStreamMmap];
 +
 + __u32 type[2];
 + FILE *file[2] = {NULL, NULL};
 + struct v4l2_requestbuffers reqbufs[2];
 +
 + type[CAP] = is_mplane ?
 + V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE : 
 V4L2_BUF_TYPE_VIDEO_CAPTURE;
 +
 + type[OUT] = is_mplane ?
 + V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE : V4L2_BUF_TYPE_VIDEO_OUTPUT;
 +
 + memset(reqbufs, 0, sizeof(reqbufs));
 +
 + reqbufs[CAP].count = reqbufs_count;

 Capture and output can have different reqbufs_count values. That static needs 
 to be
 split up in a capture and output variant.

 + reqbufs[CAP].type = type[CAP];
 + reqbufs[CAP].memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
 +
 + reqbufs[OUT].count = reqbufs_count;
 + reqbufs[OUT].type = type[OUT];
 + reqbufs[OUT].memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
 +
 + struct v4l2_event_subscription sub;
 +
 + memset(sub, 0, sizeof(sub));
 + sub.type = V4L2_EVENT_EOS;
 + ioctl(fd, VIDIOC_SUBSCRIBE_EVENT, sub);
 +
 + if (file_cap) {
 + if (!strcmp(file_cap, -))
 + file[CAP] = stdout;
 + else
 + file[CAP] = fopen(file_cap, w+);
 + }
 +
 + if (file_out) {
 + if (!strcmp(file_out, -))
 + file[OUT] = stdin;
 + else
 + file[OUT] = fopen(file_out, r);
 + }
 +
 + if (doioctl(fd, VIDIOC_REQBUFS, reqbufs[CAP]) ||
 + doioctl(fd, VIDIOC_REQBUFS, reqbufs[OUT]))
 + return;
 +
 + void *buffers[2][reqbufs_count * VIDEO_MAX_PLANES];
 + unsigned buffer_lengths[2][reqbufs_count * VIDEO_MAX_PLANES];
 +
 + do_setup_cap_buffers(fd, reqbufs[CAP], is_mplane, num_planes,
 +  is_mmap, buffers[CAP], buffer_lengths[CAP]);
 +
 + do_setup_out_buffers(fd, reqbufs[OUT], is_mplane, num_planes,
 +  is_mmap, buffers[OUT], buffer_lengths[OUT],
 +  file[OUT]);
 +
 + if (doioctl(fd, VIDIOC_STREAMON, type[CAP]) ||
 + doioctl(fd, VIDIOC_STREAMON, type[OUT]))
 + return;
 +
 + if (use_poll)
 + fcntl(fd, F_SETFL, fd_flags | O_NONBLOCK);
 +
 + unsigned count[2] = { 0, 0 };
 + unsigned last[2] = { 0, 0 };
 + struct timeval tv_last[2];
 + bool eos[2] = { false, false};

 No. eos is valid for the capture only. There is no eos[OUT].

 + fd_set read_fds;
 + fd_set write_fds;
 + fd_set exception_fds;
 +
 + while (!eos[CAP] || !eos[OUT]) {
 +
 + int r;
 +
 + if (use_poll) {
 + struct timeval tv;
 +
 + FD_ZERO(read_fds);
 + FD_SET(fd, read_fds);
 +
 + FD_ZERO(write_fds);
 + FD_SET(fd, write_fds);
 +
 + FD_ZERO(exception_fds);
 + FD_SET(fd, exception_fds);
 +
 + /* Timeout. */
 + tv.tv_sec = 2;
 + tv.tv_usec = 0;
 +
 + r = select(fd + 1, read_fds, write_fds, 
 exception_fds, tv);
 +
 + if (r == -1) {
 + if (EINTR == errno)
 + continue;
 + fprintf(stderr, select error: %s\n,
 + strerror(errno));
 + return;
 + }
 +
 + if (r == 0) {
 + fprintf(stderr, select timeout\n);
 +

Re: [PATCH 2/2] v4l2-ctl: initial attempt to support M2M device streaming

2013-04-10 Thread Hans Verkuil
On Wed 10 April 2013 10:38:13 Tzu-Jung Lee wrote:
 On Wed, Apr 10, 2013 at 2:48 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  + if (!eos[OUT]) {
  + if (FD_ISSET(fd, write_fds)) {
  + r  = do_handle_out(fd, reqbufs[OUT], 
  is_mplane, num_planes,
  +buffers[OUT], 
  buffer_lengths[OUT], file[OUT],
  +count[OUT], last[OUT], 
  tv_last[OUT]);
  + if (r  0)  {
  + eos[OUT] = true;
  +
  + if (options[OptDecoderCmd]) {
  + doioctl(fd, 
  VIDIOC_DECODER_CMD, dec_cmd);
  + options[OptDecoderCmd] = 
  false;
  + }
  +
  + doioctl(fd, VIDIOC_STREAMOFF, 
  type[OUT]);
  +
 
  Rather than using eos[OUT], just 'break' out of the loop here.
 
 If we break out here, the unfinished captured stream will also be left
 out, isn't it?

That's a good point. So it's OK to keep the eos[2] array. However, to make
this work correctly the while loop should use '' instead of '||'. I.e.,
only break out when both sides have eos set.

In addition, once eos is set for one of the two sides, make sure that you
no longer attempt to select on that fd for read+exception (capture) or
write (output).

You may also have to modify the way stream_count and skip are handled in
an m2m case: those should only apply to the output side of things, it
makes no sense to apply them to the capture side.

Regards,

Hans
 
 Oh, I'm working on a M2M device, which works with bitstreams only, and
 no frames on Linux.
 So we keep feeding input streams via the OUTPUT path, and get
 transcoded bitstream from
 CAPTURE path. In this case, we need to keep pulling out the transcoded
 bitstreams in the loop.
 I think this is also only relevant to compressed formats again.
 
  + }
  + }
  +
  + }
  + }
  +
  + fcntl(fd, F_SETFL, fd_flags);
  + fprintf(stderr, \n);
  +
  + do_release_buffers(reqbufs[CAP], num_planes, is_mmap,
  +buffers[CAP], buffer_lengths[CAP]);
  +
  + do_release_buffers(reqbufs[OUT], num_planes, is_mmap,
  +buffers[OUT], buffer_lengths[OUT]);
  +
  + if (file[CAP]  file[CAP] != stdout)
  + fclose(file[CAP]);
  +
  + if (file[OUT]  file[OUT] != stdin)
  + fclose(file[OUT]);
  +}
  +
   void streaming_set(int fd)
   {
bool do_cap = options[OptStreamMmap] || options[OptStreamUser];
bool do_out = options[OptStreamOutMmap] || options[OptStreamOutUser];
 
  - if (do_cap)
  + if (do_cap  do_out)
  + streaming_set_m2m(fd);
  + else if (do_cap)
streaming_set_cap(fd);
else if (do_out)
streaming_set_out(fd);
 
 
  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 v2 2/3] mutex: add support for reservation style locks, v2

2013-04-10 Thread Daniel Vetter
On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
 On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
  On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
   The thing is now that you're not expected to hold these locks for a
   long
   time - if you need to synchronously stall while holding a lock
   performance
   will go down the gutters anyway. And since most current
   gpus/co-processors
   still can't really preempt fairness isn't that high a priority,
   either.
   So we didn't think too much about that.
  
  Yeah but you're proposing a new synchronization primitive for the core
  kernel.. all such 'fun' details need to be considered, not only those
  few that bear on the one usecase.
 
 Which bares the question, what other use cases are there?

Tbh I don't see any other either - but I agree with Peter and thinking
things through and making the api a bit more generic seems to help in
clarifying the semantics. Reminds me that I still need to draw a few
diagrams ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] s5p-mfc: Remove potential uninitialized variable usage

2013-04-10 Thread Sylwester Nawrocki
Make sure mem_info[] array is not used uninitialized. This prevents
following compiler warning:

drivers/media/platform/s5p-mfc/s5p_mfc.c: In function s5p_mfc_probe:
drivers/media/platform/s5p-mfc/s5p_mfc.c:1032:33: warning: mem_info[0] may be 
used uninitialized in this function [-Wuninitialized]
drivers/media/platform/s5p-mfc/s5p_mfc.c:1021:15: note: mem_info[0] was 
declared here
drivers/media/platform/s5p-mfc/s5p_mfc.c:1032:33: warning: mem_info[1] may be 
used uninitialized in this function [-Wuninitialized]
drivers/media/platform/s5p-mfc/s5p_mfc.c:1021:15: note: mem_info[1] was 
declared here

Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 7379dc6..5fb948c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1018,7 +1018,7 @@ static void *mfc_get_drv_data(struct platform_device 
*pdev);
 
 static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
 {
-   unsigned int mem_info[2];
+   unsigned int mem_info[2] = { };
 
dev-mem_dev_l = devm_kzalloc(dev-plat_dev-dev,
sizeof(struct device), GFP_KERNEL);
-- 
1.7.9.5

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


Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

2013-04-10 Thread Daniel Vetter
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
 On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
  On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
   Presuming I'm still following we should be able to fix this with the
   new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
   (let's call it PF_GTFO for simplicity).
  
  I'm reading Get The F*ck Out ? I like the name, except PF_flags are
  unsuitable since they are not atomic and we'd need to set it from
  another thread.
 
 I think the PF_ flag is a non-starter for a different reason, too. To make
 different clases of ww_mutexes nest properly, we need to make sure that we
 don't dead/live-lock trying to wake up a task holdinga ww_mutex of class
 A, while that task is trying to acquire ww_mutexes of class B. Picture:
 
   task 1  task 2  task 3
   holds lock B
   ticket_A = acquire_start(class A)
   ww_mutex_lock(lock A, ticket_A) busy doing something
 
   ticket_B = acquire_start(class B)
   ww_mutex_lock(lock B, ticket_B)
   - contention with task 3
   
   ticket_task2 = acquire_start(class A)
   ww_mutex_lock(lock A, ticket_task2)
   - contention with task 1
 
 If we go with the PF_GTFO task flag, task 2 will set it on task 1
 (handwave locking/atomicity again here ;-). But taks 1 will only back off
 from any locks in class B. Or at least I think we should impose that
 restriction, since otherwise a ww_mutex acquire loop will leak out badly
 abstraction-wise and making nesting pretty much impossible in practice.
 
 But if we really want nesting to work transparently, then task 1 should be
 allowed to continue taking locks from class A (after an acquire_end(class
 B) call ofc). But then it will have missed the wakeup from task 2, so task
 2 blocks for too long and task 1 doesn't back off from further acquiring
 locks in class A.
 
 Presuming my reasoning for the rt case isn't broken, this break deadlock
 avoidance if we sort by (rt_prio, ticket).
 
 So I think we need to move the PF_GTFO flag to the ticket to make sure
 that task1 will notice that there's contention with one of the locks it
 holds from class A and that it better gtfo asap (i.e. back off, drop all
 currently held locks in class A and go into the slowpath).
 
 But I still need to think the nesting case through a bit more (and draw
 some diagrams), so not sure yet. One thing I still need to ponder is how
 to best stack tickets (for tasks doing nested ww_mutex locking) and where
 all we need a pointer to relevant tickets and what kind of fun this
 entails ... I need to ponder this some more.

Ok, so I think the nesting case should all work if we have a
per-task/ticket flag to signal contention. The point I've mused over a bit
is how to get at both the flag and the corresponding task to do the
wakeup. I think for non-rt the simplest way is to store a pointer to the
ticket in the ww_mutex, and the ticket the holds both the contention flag
and a pointer to the task. Lifetime of that stuff would be protected by
the wait_lock from disappearing untimely, which should allow the
lock/unlock fastpaths to set/clear it non-atomically - only careful places
is in the contented unlock slowpath. So rough api sketch for nesting
ww_mutexes:

struct ww_class {
atomic_t next_ticket;
/* virtual lock to annotate the acquire_start/end sections. */
struct lock_class_key acquire_key;
/* lockdep class of all ww_mutexes in this class */
struct lock_class_key mutex_key;
/* for debug/tracepts */
const char *name 
};

DEFINE_WW_CLASS(name) /* ... and all the other usual magic init funcitons */

struct ww_acquire_ctx {
struct task_struct *task; /* invariant */
usinged ticket; /* invariant */
/* atomic is probably overkill, but need to review the resulting
 * code with all the barriers first. */
atomic_t contention;
}

void ww_acquire_start(struct ww_acuire_ctx *ctx, struct ww_class *class);
void ww_acquire_end(struct ww_acuire_ctx *ctx);

Originally I've thought we could store the pointer to the current acquire
ctx in task_struct (since we need that handy for PI boosting anyway), but
that makes things a bit ugly with nesting. Having a (somewhat) redundant
pointer to the acquiring taks in the ctx seemed less evil.

struct ww_mutex {
struct mutex base;
struct ww_acquire_ctx *holding_ctx;
}

I've considered whether we should try to pull clever tricks like with
lockdep keys and make the ww_class more implicit (by auto-instantiating it
somewhere and adding a pointer to it in each ww_mutex). But I think we
should not hide this complexity, but instead make it explicit.

All the ww_mutex_(un)lock* variants would then also need to 

Re: [PATCH 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Barry Song
Hi Guennadia,

2012/9/27 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 Currently soc-camera doesn't work with independently registered I2C client
 devices, it has to register them itself. This patch adds support for such
 configurations, in which case client drivers have to request deferred
 probing until their host becomes available and enables the data interface.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---

it seems deferred probing for i2c camera sensors is a more workaround
than a solution.
currently,  soc-camera-pdrv is the manager of the whole initilization
flow. it all requires the host/client registerred and initilized
synchronously. so that results in strange things like that we fill a
i2c_board_info structure in arch/arm/mach-xxx but we never call
anything like i2c_new_device() to add the i2c client in mach. because
we need to do that in the soc-camera-pdrv driver to make all things
happen orderly.

but now after we move to DT, all i2c device will be registerred
automatically by of_i2c_register_devices() in i2c_host 's probe, that
makes the problem much worse and very urgent to get fixed.

returning DEFERRED_PROBE error until getting the private data filled
by the manager, indirectly, makes the things seem to be asynchronous,
but essentially it is still synchronous because the overall timing
line is still controller by soc-camera-pdrv.

what about another possible way:
we let all host and i2c client driver probed in any order, but let the
final soc-camera-pdrv is the connection of all things. the situation
of soc_camera is very similar with ALSA SoC. it turns out ASoC has
done that very well.

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


[PATCH 0/7] exynos4-is cleanups and improvements

2013-04-10 Thread Sylwester Nawrocki
This patch series includes some cleanups of the recently added FIMC-IS
driver and prerequisite patches for the FIMC-LITE module to make it
easier to reuse in the future exynos5-is driver.

Sylwester Nawrocki (7):
  exynos4-is: Move the subdev group ID definitions to public header
  exynos4-is: Make fimc-lite independent of the pipeline-subdevs array
  exynos4-is: Make fimc-lite independent on struct fimc_sensor_info
  exynos4-is: Improve the ISP chain parameter count calculation
  exynos4-is: Rename the ISP chain configuration data structure
  exynos4-is: Remove meaningless test before bit setting
  exynos4-is: Disable debug trace by default in fimc-isp.c

 drivers/media/platform/exynos4-is/fimc-capture.c  |7 +-
 drivers/media/platform/exynos4-is/fimc-is-param.c |  277 +
 drivers/media/platform/exynos4-is/fimc-is-param.h |4 +-
 drivers/media/platform/exynos4-is/fimc-is-regs.c  |   17 +-
 drivers/media/platform/exynos4-is/fimc-is.c   |   24 +-
 drivers/media/platform/exynos4-is/fimc-is.h   |   10 +-
 drivers/media/platform/exynos4-is/fimc-isp.c  |   15 +-
 drivers/media/platform/exynos4-is/fimc-lite.c |   67 ++---
 drivers/media/platform/exynos4-is/media-dev.c |   74 +++---
 drivers/media/platform/exynos4-is/media-dev.h |   15 +-
 include/media/s5p_fimc.h  |   11 +
 11 files changed, 238 insertions(+), 283 deletions(-)

--
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 1/7] exynos4-is: Move the subdev group ID definitions to public header

2013-04-10 Thread Sylwester Nawrocki
Move the sub-device group ID definitions to the driver's public header
so they are available to other media drivers that need to share modules
found in exynos4-is.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/media-dev.h |9 -
 include/media/s5p_fimc.h  |   11 +++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/media-dev.h 
b/drivers/media/platform/exynos4-is/media-dev.h
index 0b14cd5..7f126c3 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -30,15 +30,6 @@
 
 #define PINCTRL_STATE_IDLE idle
 
-/* Group IDs of sensor, MIPI-CSIS, FIMC-LITE and the writeback subdevs. */
-#define GRP_ID_SENSOR  (1  8)
-#define GRP_ID_FIMC_IS_SENSOR  (1  9)
-#define GRP_ID_WRITEBACK   (1  10)
-#define GRP_ID_CSIS(1  11)
-#define GRP_ID_FIMC(1  12)
-#define GRP_ID_FLITE   (1  13)
-#define GRP_ID_FIMC_IS (1  14)
-
 #define FIMC_MAX_SENSORS   8
 #define FIMC_MAX_CAMCLKS   2
 
diff --git a/include/media/s5p_fimc.h b/include/media/s5p_fimc.h
index e316d15..f509690 100644
--- a/include/media/s5p_fimc.h
+++ b/include/media/s5p_fimc.h
@@ -49,6 +49,17 @@ enum fimc_bus_type {
 #define fimc_input_is_parallel(x) ((x) == 1 || (x) == 2)
 #define fimc_input_is_mipi_csi(x) ((x) == 3 || (x) == 4)
 
+/*
+ * The subdevices' group IDs.
+ */
+#define GRP_ID_SENSOR  (1  8)
+#define GRP_ID_FIMC_IS_SENSOR  (1  9)
+#define GRP_ID_WRITEBACK   (1  10)
+#define GRP_ID_CSIS(1  11)
+#define GRP_ID_FIMC(1  12)
+#define GRP_ID_FLITE   (1  13)
+#define GRP_ID_FIMC_IS (1  14)
+
 struct i2c_board_info;
 
 /**
-- 
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 2/7] exynos4-is: Make fimc-lite independent of the pipeline-subdevs array

2013-04-10 Thread Sylwester Nawrocki
Get the sensor subdev by walking media graph in both cases: when the
device is used as a subdev only and through video node. This allows
to not dereference the pipeline-subdevs[] array and makes the module
more generic and easier to re-use in other media driver.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/fimc-lite.c |   57 -
 1 file changed, 28 insertions(+), 29 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index cb196b8..3ea4fc7 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -130,23 +130,43 @@ static const struct fimc_fmt *fimc_lite_find_format(const 
u32 *pixelformat,
return def_fmt;
 }
 
+/* Called with the media graph mutex held or @me stream_count  0. */
+static struct v4l2_subdev *__find_remote_sensor(struct media_entity *me)
+{
+   struct media_pad *pad = me-pads[0];
+   struct v4l2_subdev *sd;
+
+   while (pad-flags  MEDIA_PAD_FL_SINK) {
+   /* source pad */
+   pad = media_entity_remote_source(pad);
+   if (pad == NULL ||
+   media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
+   break;
+
+   sd = media_entity_to_v4l2_subdev(pad-entity);
+
+   if (sd-grp_id == GRP_ID_FIMC_IS_SENSOR ||
+   sd-grp_id == GRP_ID_SENSOR)
+   return sd;
+   /* sink pad */
+   pad = sd-entity.pads[0];
+   }
+   return NULL;
+}
+
 static int fimc_lite_hw_init(struct fimc_lite *fimc, bool isp_output)
 {
-   struct fimc_pipeline *pipeline = fimc-pipeline;
-   struct v4l2_subdev *sensor;
struct fimc_sensor_info *si;
unsigned long flags;
 
-   sensor = isp_output ? fimc-sensor : pipeline-subdevs[IDX_SENSOR];
-
-   if (sensor == NULL)
+   if (fimc-sensor == NULL)
return -ENXIO;
 
if (fimc-inp_frame.fmt == NULL || fimc-out_frame.fmt == NULL)
return -EINVAL;
 
/* Get sensor configuration data from the sensor subdev */
-   si = v4l2_get_subdev_hostdata(sensor);
+   si = v4l2_get_subdev_hostdata(fimc-sensor);
spin_lock_irqsave(fimc-slock, flags);
 
flite_hw_set_camera_bus(fimc, si-pdata);
@@ -801,6 +821,8 @@ static int fimc_lite_streamon(struct file *file, void *priv,
if (ret  0)
goto err_p_stop;
 
+   fimc-sensor = __find_remote_sensor(fimc-subdev.entity);
+
ret = vb2_ioctl_streamon(file, priv, type);
if (!ret) {
fimc-streaming = true;
@@ -929,29 +951,6 @@ static const struct v4l2_ioctl_ops fimc_lite_ioctl_ops = {
.vidioc_streamoff   = fimc_lite_streamoff,
 };
 
-/* Called with the media graph mutex held */
-static struct v4l2_subdev *__find_remote_sensor(struct media_entity *me)
-{
-   struct media_pad *pad = me-pads[0];
-   struct v4l2_subdev *sd;
-
-   while (pad-flags  MEDIA_PAD_FL_SINK) {
-   /* source pad */
-   pad = media_entity_remote_source(pad);
-   if (pad == NULL ||
-   media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
-   break;
-
-   sd = media_entity_to_v4l2_subdev(pad-entity);
-
-   if (sd-grp_id == GRP_ID_FIMC_IS_SENSOR)
-   return sd;
-   /* sink pad */
-   pad = sd-entity.pads[0];
-   }
-   return NULL;
-}
-
 /* Capture subdev media entity operations */
 static int fimc_lite_link_setup(struct media_entity *entity,
const struct media_pad *local,
-- 
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 3/7] exynos4-is: Make fimc-lite independent on struct fimc_sensor_info

2013-04-10 Thread Sylwester Nawrocki
Make the sensor subdevs host_data hold a pointer to struct fimc_source_info,
which is defined in the driver's public header, rather than a pointer to
struct fimc_sensor_info which is specific to exynos4-is media device driver.

The purpose of this change is to allow easier reuse of the fimc-lite module
in the exynos5-is driver, which should similarly store a pointer to struct
fimc_source_info instance in the sensor's subdev host_data.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/fimc-capture.c |7 +-
 drivers/media/platform/exynos4-is/fimc-lite.c|   10 ++-
 drivers/media/platform/exynos4-is/media-dev.c|   74 +++---
 drivers/media/platform/exynos4-is/media-dev.h|6 ++
 4 files changed, 54 insertions(+), 43 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c 
b/drivers/media/platform/exynos4-is/fimc-capture.c
index 28c6b26..72c516a 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -1450,7 +1450,7 @@ static const struct media_entity_operations 
fimc_sd_media_ops = {
 void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
void *arg)
 {
-   struct fimc_sensor_info *sensor;
+   struct fimc_source_info *si;
struct fimc_vid_buffer *buf;
struct fimc_md *fmd;
struct fimc_dev *fimc;
@@ -1459,11 +1459,12 @@ void fimc_sensor_notify(struct v4l2_subdev *sd, 
unsigned int notification,
if (sd == NULL)
return;
 
-   sensor = v4l2_get_subdev_hostdata(sd);
+   si = v4l2_get_subdev_hostdata(sd);
fmd = entity_to_fimc_mdev(sd-entity);
 
spin_lock_irqsave(fmd-slock, flags);
-   fimc = sensor ? sensor-host : NULL;
+
+   fimc = si ? source_to_sensor_info(si)-host : NULL;
 
if (fimc  arg  notification == S5P_FIMC_TX_END_NOTIFY 
test_bit(ST_CAPT_PEND, fimc-state)) {
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c 
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 3ea4fc7..661d0d1 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -11,6 +11,7 @@
 #define pr_fmt(fmt) %s:%d  fmt, __func__, __LINE__
 
 #include linux/bug.h
+#include linux/clk.h
 #include linux/device.h
 #include linux/errno.h
 #include linux/interrupt.h
@@ -31,7 +32,7 @@
 #include media/videobuf2-dma-contig.h
 #include media/s5p_fimc.h
 
-#include media-dev.h
+#include fimc-core.h
 #include fimc-lite.h
 #include fimc-lite-reg.h
 
@@ -156,7 +157,7 @@ static struct v4l2_subdev *__find_remote_sensor(struct 
media_entity *me)
 
 static int fimc_lite_hw_init(struct fimc_lite *fimc, bool isp_output)
 {
-   struct fimc_sensor_info *si;
+   struct fimc_source_info *si;
unsigned long flags;
 
if (fimc-sensor == NULL)
@@ -167,9 +168,12 @@ static int fimc_lite_hw_init(struct fimc_lite *fimc, bool 
isp_output)
 
/* Get sensor configuration data from the sensor subdev */
si = v4l2_get_subdev_hostdata(fimc-sensor);
+   if (!si)
+   return -EINVAL;
+
spin_lock_irqsave(fimc-slock, flags);
 
-   flite_hw_set_camera_bus(fimc, si-pdata);
+   flite_hw_set_camera_bus(fimc, si);
flite_hw_set_source_format(fimc, fimc-inp_frame);
flite_hw_set_window_offset(fimc, fimc-inp_frame);
flite_hw_set_output_dma(fimc, fimc-out_frame, !isp_output);
diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index 44d6c1d..1dbd554 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -37,7 +37,7 @@
 #include mipi-csis.h
 
 static int __fimc_md_set_camclk(struct fimc_md *fmd,
-   struct fimc_sensor_info *s_info,
+   struct fimc_source_info *si,
bool on);
 /**
  * fimc_pipeline_prepare - update pipeline information with subdevice pointers
@@ -281,36 +281,36 @@ static const struct fimc_pipeline_ops fimc_pipeline_ops = 
{
  * Sensor subdevice helper functions
  */
 static struct v4l2_subdev *fimc_md_register_sensor(struct fimc_md *fmd,
-  struct fimc_sensor_info *s_info)
+   struct fimc_source_info *si)
 {
struct i2c_adapter *adapter;
struct v4l2_subdev *sd = NULL;
 
-   if (!s_info || !fmd)
+   if (!si || !fmd)
return NULL;
/*
 * If FIMC bus type is not Writeback FIFO assume it is same
 * as sensor_bus_type.
 */
-   s_info-pdata.fimc_bus_type = s_info-pdata.sensor_bus_type;
+   si-fimc_bus_type = si-sensor_bus_type;
 
-   adapter = i2c_get_adapter(s_info-pdata.i2c_bus_num);
+   adapter = 

[PATCH 4/7] exynos4-is: Improve the ISP chain parameter count calculation

2013-04-10 Thread Sylwester Nawrocki
Instead of incrementing p_region_num field each time we set a bit
in the parameter mask calculate the number of bits set only when
this information is needed.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/fimc-is-param.c |   86 +++--
 drivers/media/platform/exynos4-is/fimc-is-param.h |4 +-
 drivers/media/platform/exynos4-is/fimc-is-regs.c  |3 +-
 drivers/media/platform/exynos4-is/fimc-is.c   |2 -
 drivers/media/platform/exynos4-is/fimc-is.h   |1 -
 drivers/media/platform/exynos4-is/fimc-isp.c  |7 +-
 6 files changed, 34 insertions(+), 69 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-is-param.c 
b/drivers/media/platform/exynos4-is/fimc-is-param.c
index 37fd5fe..58123e3 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-param.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-param.c
@@ -12,14 +12,15 @@
  */
 #define pr_fmt(fmt) %s:%d  fmt, __func__, __LINE__
 
+#include linux/bitops.h
 #include linux/bug.h
 #include linux/device.h
 #include linux/errno.h
 #include linux/kernel.h
 #include linux/module.h
-#include linux/types.h
 #include linux/platform_device.h
 #include linux/slab.h
+#include linux/types.h
 #include linux/videodev2.h
 
 #include media/v4l2-device.h
@@ -160,6 +161,20 @@ int __fimc_is_hw_update_param(struct fimc_is *is, u32 
offset)
return 0;
 }
 
+unsigned int __get_pending_param_count(struct fimc_is *is)
+{
+   struct is_config_param *config = is-cfg_param[is-scenario_id];
+   unsigned long flags;
+   unsigned int count;
+
+   spin_lock_irqsave(is-slock, flags);
+   count = hweight32(config-p_region_index1);
+   count += hweight32(config-p_region_index2);
+   spin_unlock_irqrestore(is-slock, flags);
+
+   return count;
+}
+
 int __is_hw_update_params(struct fimc_is *is)
 {
unsigned long *p_index1, *p_index2;
@@ -234,15 +249,10 @@ void __is_set_frame_size(struct fimc_is *is, struct 
v4l2_mbus_framefmt *mf)
 
/* Update field */
fimc_is_set_param_bit(is, PARAM_ISP_OTF_INPUT);
-   fimc_is_inc_param_num(is);
fimc_is_set_param_bit(is, PARAM_ISP_OTF_OUTPUT);
-   fimc_is_inc_param_num(is);
fimc_is_set_param_bit(is, PARAM_DRC_OTF_INPUT);
-   fimc_is_inc_param_num(is);
fimc_is_set_param_bit(is, PARAM_DRC_OTF_OUTPUT);
-   fimc_is_inc_param_num(is);
fimc_is_set_param_bit(is, PARAM_FD_OTF_INPUT);
-   fimc_is_inc_param_num(is);
 }
 
 int fimc_is_hw_get_sensor_max_framerate(struct fimc_is *is)
@@ -277,14 +287,11 @@ void __is_set_sensor(struct fimc_is *is, int fps)
isp-otf_input.frametime_max = (u32)100 / fps;
}
 
-   if (!test_bit(PARAM_SENSOR_FRAME_RATE, p_index)) {
+   if (!test_bit(PARAM_SENSOR_FRAME_RATE, p_index))
fimc_is_set_param_bit(is, PARAM_SENSOR_FRAME_RATE);
-   fimc_is_inc_param_num(is);
-   }
-   if (!test_bit(PARAM_ISP_OTF_INPUT, p_index)) {
+
+   if (!test_bit(PARAM_ISP_OTF_INPUT, p_index))
fimc_is_set_param_bit(is, PARAM_ISP_OTF_INPUT);
-   fimc_is_inc_param_num(is);
-   }
 }
 
 void __is_set_init_isp_aa(struct fimc_is *is)
@@ -306,7 +313,6 @@ void __is_set_init_isp_aa(struct fimc_is *is)
isp-aa.err = ISP_AF_ERROR_NONE;
 
fimc_is_set_param_bit(is, PARAM_ISP_AA);
-   fimc_is_inc_param_num(is);
 }
 
 void __is_set_isp_flash(struct fimc_is *is, u32 cmd, u32 redeye)
@@ -319,10 +325,8 @@ void __is_set_isp_flash(struct fimc_is *is, u32 cmd, u32 
redeye)
isp-flash.redeye = redeye;
isp-flash.err = ISP_FLASH_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_FLASH, cfg-p_region_index1)) {
+   if (!test_bit(PARAM_ISP_FLASH, cfg-p_region_index1))
fimc_is_set_param_bit(is, PARAM_ISP_FLASH);
-   fimc_is_inc_param_num(is);
-   }
 }
 
 void __is_set_isp_awb(struct fimc_is *is, u32 cmd, u32 val)
@@ -338,10 +342,8 @@ void __is_set_isp_awb(struct fimc_is *is, u32 cmd, u32 val)
isp-awb.illumination = val;
isp-awb.err = ISP_AWB_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_AWB, p_index)) {
+   if (!test_bit(PARAM_ISP_AWB, p_index))
fimc_is_set_param_bit(is, PARAM_ISP_AWB);
-   fimc_is_inc_param_num(is);
-   }
 }
 
 void __is_set_isp_effect(struct fimc_is *is, u32 cmd)
@@ -356,10 +358,8 @@ void __is_set_isp_effect(struct fimc_is *is, u32 cmd)
isp-effect.cmd = cmd;
isp-effect.err = ISP_IMAGE_EFFECT_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_IMAGE_EFFECT, p_index)) {
+   if (!test_bit(PARAM_ISP_IMAGE_EFFECT, p_index))
fimc_is_set_param_bit(is, PARAM_ISP_IMAGE_EFFECT);
-   fimc_is_inc_param_num(is);
-   }
 }
 
 void __is_set_isp_iso(struct fimc_is *is, u32 cmd, u32 val)
@@ -375,10 +375,8 @@ void __is_set_isp_iso(struct fimc_is *is, u32 cmd, u32 

[PATCH 5/7] exynos4-is: Rename the ISP chain configuration data structure

2013-04-10 Thread Sylwester Nawrocki
More appropriate names for the ISP chain data structure.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/fimc-is-param.c |  191 ++---
 drivers/media/platform/exynos4-is/fimc-is-regs.c  |   14 +-
 drivers/media/platform/exynos4-is/fimc-is.c   |   22 +--
 drivers/media/platform/exynos4-is/fimc-is.h   |9 +-
 drivers/media/platform/exynos4-is/fimc-isp.c  |6 +-
 5 files changed, 121 insertions(+), 121 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-is-param.c 
b/drivers/media/platform/exynos4-is/fimc-is-param.c
index 58123e3..254740f 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-param.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-param.c
@@ -43,7 +43,7 @@ void __fimc_is_hw_update_param_global_shotmode(struct fimc_is 
*is)
struct param_global_shotmode *dst, *src;
 
dst = is-is_p_region-parameter.global.shotmode;
-   src = is-cfg_param[is-scenario_id].global.shotmode;
+   src = is-config[is-config_index].global.shotmode;
__hw_param_copy(dst, src);
 }
 
@@ -52,14 +52,14 @@ void __fimc_is_hw_update_param_sensor_framerate(struct 
fimc_is *is)
struct param_sensor_framerate *dst, *src;
 
dst = is-is_p_region-parameter.sensor.frame_rate;
-   src = is-cfg_param[is-scenario_id].sensor.frame_rate;
+   src = is-config[is-config_index].sensor.frame_rate;
__hw_param_copy(dst, src);
 }
 
 int __fimc_is_hw_update_param(struct fimc_is *is, u32 offset)
 {
struct is_param_region *par = is-is_p_region-parameter;
-   struct is_config_param *cfg = is-cfg_param[is-scenario_id];
+   struct chain_config *cfg = is-config[is-config_index];
 
switch (offset) {
case PARAM_ISP_CONTROL:
@@ -163,7 +163,7 @@ int __fimc_is_hw_update_param(struct fimc_is *is, u32 
offset)
 
 unsigned int __get_pending_param_count(struct fimc_is *is)
 {
-   struct is_config_param *config = is-cfg_param[is-scenario_id];
+   struct chain_config *config = is-config[is-config_index];
unsigned long flags;
unsigned int count;
 
@@ -180,9 +180,9 @@ int __is_hw_update_params(struct fimc_is *is)
unsigned long *p_index1, *p_index2;
int i, id, ret = 0;
 
-   id = is-scenario_id;
-   p_index1 = is-cfg_param[id].p_region_index1;
-   p_index2 = is-cfg_param[id].p_region_index2;
+   id = is-config_index;
+   p_index1 = is-config[id].p_region_index1;
+   p_index2 = is-config[id].p_region_index2;
 
if (test_bit(PARAM_GLOBAL_SHOTMODE, p_index1))
__fimc_is_hw_update_param_global_shotmode(is);
@@ -212,22 +212,21 @@ void __is_get_frame_size(struct fimc_is *is, struct 
v4l2_mbus_framefmt *mf)
 {
struct isp_param *isp;
 
-   isp = is-cfg_param[is-scenario_id].isp;
+   isp = is-config[is-config_index].isp;
mf-width = isp-otf_input.width;
mf-height = isp-otf_input.height;
 }
 
 void __is_set_frame_size(struct fimc_is *is, struct v4l2_mbus_framefmt *mf)
 {
+   unsigned int index = is-config_index;
struct isp_param *isp;
struct drc_param *drc;
struct fd_param *fd;
-   unsigned int mode;
 
-   mode = is-scenario_id;
-   isp = is-cfg_param[mode].isp;
-   drc = is-cfg_param[mode].drc;
-   fd = is-cfg_param[mode].fd;
+   isp = is-config[index].isp;
+   drc = is-config[index].drc;
+   fd = is-config[index].fd;
 
/* Update isp size info (OTF only) */
isp-otf_input.width = mf-width;
@@ -244,7 +243,7 @@ void __is_set_frame_size(struct fimc_is *is, struct 
v4l2_mbus_framefmt *mf)
fd-otf_input.height = mf-height;
 
if (test_bit(PARAM_ISP_OTF_INPUT,
- is-cfg_param[mode].p_region_index1))
+ is-config[index].p_region_index1))
return;
 
/* Update field */
@@ -267,14 +266,14 @@ int fimc_is_hw_get_sensor_max_framerate(struct fimc_is 
*is)
 
 void __is_set_sensor(struct fimc_is *is, int fps)
 {
+   unsigned int index = is-config_index;
struct sensor_param *sensor;
struct isp_param *isp;
-   unsigned long *p_index, mode;
+   unsigned long *p_index;
 
-   mode = is-scenario_id;
-   p_index = is-cfg_param[mode].p_region_index1;
-   sensor = is-cfg_param[mode].sensor;
-   isp = is-cfg_param[mode].isp;
+   p_index = is-config[index].p_region_index1;
+   sensor = is-config[index].sensor;
+   isp = is-config[index].isp;
 
if (fps == 0) {
sensor-frame_rate.frame_rate =
@@ -298,7 +297,7 @@ void __is_set_init_isp_aa(struct fimc_is *is)
 {
struct isp_param *isp;
 
-   isp = is-cfg_param[is-scenario_id].isp;
+   isp = is-config[is-config_index].isp;
 
isp-aa.cmd = ISP_AA_COMMAND_START;
isp-aa.target = ISP_AA_TARGET_AF | ISP_AA_TARGET_AE |
@@ -317,8 +316,8 @@ void 

[PATCH 7/7] exynos4-is: Disable debug trace by default in fimc-isp.c

2013-04-10 Thread Sylwester Nawrocki
Make sure the debug level is properly set initially so any debug
information is not printed to the kernel log without explicitly
enabling it.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/fimc-isp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c 
b/drivers/media/platform/exynos4-is/fimc-isp.c
index 7b8fbab..3b9a664 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -30,7 +30,7 @@
 #include fimc-is-regs.h
 #include fimc-is.h
 
-static int debug = 10;
+static int debug;
 module_param_named(debug_isp, debug, int, S_IRUGO | S_IWUSR);
 
 static const struct fimc_fmt fimc_isp_formats[FIMC_ISP_NUM_FORMATS] = {
-- 
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 6/7] exynos4-is: Remove meaningless test before bit setting

2013-04-10 Thread Sylwester Nawrocki
There is no need to check same bit before setting it, since we
always end up with a bit set. Remove some of the tests and make
set unconditional, in every place where all that needs to be done
is just setting a bit.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/platform/exynos4-is/fimc-is-param.c |   40 +
 1 file changed, 9 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-is-param.c 
b/drivers/media/platform/exynos4-is/fimc-is-param.c
index 254740f..53fe2a2 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-param.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-param.c
@@ -269,9 +269,7 @@ void __is_set_sensor(struct fimc_is *is, int fps)
unsigned int index = is-config_index;
struct sensor_param *sensor;
struct isp_param *isp;
-   unsigned long *p_index;
 
-   p_index = is-config[index].p_region_index1;
sensor = is-config[index].sensor;
isp = is-config[index].isp;
 
@@ -286,11 +284,8 @@ void __is_set_sensor(struct fimc_is *is, int fps)
isp-otf_input.frametime_max = (u32)100 / fps;
}
 
-   if (!test_bit(PARAM_SENSOR_FRAME_RATE, p_index))
-   fimc_is_set_param_bit(is, PARAM_SENSOR_FRAME_RATE);
-
-   if (!test_bit(PARAM_ISP_OTF_INPUT, p_index))
-   fimc_is_set_param_bit(is, PARAM_ISP_OTF_INPUT);
+   fimc_is_set_param_bit(is, PARAM_SENSOR_FRAME_RATE);
+   fimc_is_set_param_bit(is, PARAM_ISP_OTF_INPUT);
 }
 
 void __is_set_init_isp_aa(struct fimc_is *is)
@@ -317,65 +312,54 @@ void __is_set_init_isp_aa(struct fimc_is *is)
 void __is_set_isp_flash(struct fimc_is *is, u32 cmd, u32 redeye)
 {
unsigned int index = is-config_index;
-   struct chain_config *cfg = is-config[index];
-   struct isp_param *isp = cfg-isp;
+   struct isp_param *isp = is-config[index].isp;
 
isp-flash.cmd = cmd;
isp-flash.redeye = redeye;
isp-flash.err = ISP_FLASH_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_FLASH, cfg-p_region_index1))
-   fimc_is_set_param_bit(is, PARAM_ISP_FLASH);
+   fimc_is_set_param_bit(is, PARAM_ISP_FLASH);
 }
 
 void __is_set_isp_awb(struct fimc_is *is, u32 cmd, u32 val)
 {
unsigned int index = is-config_index;
struct isp_param *isp;
-   unsigned long *p_index;
 
-   p_index = is-config[index].p_region_index1;
isp = is-config[index].isp;
 
isp-awb.cmd = cmd;
isp-awb.illumination = val;
isp-awb.err = ISP_AWB_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_AWB, p_index))
-   fimc_is_set_param_bit(is, PARAM_ISP_AWB);
+   fimc_is_set_param_bit(is, PARAM_ISP_AWB);
 }
 
 void __is_set_isp_effect(struct fimc_is *is, u32 cmd)
 {
unsigned int index = is-config_index;
struct isp_param *isp;
-   unsigned long *p_index;
 
-   p_index = is-config[index].p_region_index1;
isp = is-config[index].isp;
 
isp-effect.cmd = cmd;
isp-effect.err = ISP_IMAGE_EFFECT_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_IMAGE_EFFECT, p_index))
-   fimc_is_set_param_bit(is, PARAM_ISP_IMAGE_EFFECT);
+   fimc_is_set_param_bit(is, PARAM_ISP_IMAGE_EFFECT);
 }
 
 void __is_set_isp_iso(struct fimc_is *is, u32 cmd, u32 val)
 {
unsigned int index = is-config_index;
struct isp_param *isp;
-   unsigned long *p_index;
 
-   p_index = is-config[index].p_region_index1;
isp = is-config[index].isp;
 
isp-iso.cmd = cmd;
isp-iso.value = val;
isp-iso.err = ISP_ISO_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_ISO, p_index))
-   fimc_is_set_param_bit(is, PARAM_ISP_ISO);
+   fimc_is_set_param_bit(is, PARAM_ISP_ISO);
 }
 
 void __is_set_isp_adjust(struct fimc_is *is, u32 cmd, u32 val)
@@ -464,32 +448,26 @@ void __is_set_isp_afc(struct fimc_is *is, u32 cmd, u32 
val)
 {
unsigned int index = is-config_index;
struct isp_param *isp;
-   unsigned long *p_index;
 
-   p_index = is-config[index].p_region_index1;
isp = is-config[index].isp;
 
isp-afc.cmd = cmd;
isp-afc.manual = val;
isp-afc.err = ISP_AFC_ERROR_NONE;
 
-   if (!test_bit(PARAM_ISP_AFC, p_index))
-   fimc_is_set_param_bit(is, PARAM_ISP_AFC);
+   fimc_is_set_param_bit(is, PARAM_ISP_AFC);
 }
 
 void __is_set_drc_control(struct fimc_is *is, u32 val)
 {
unsigned int index = is-config_index;
struct drc_param *drc;
-   unsigned long *p_index;
 
-   p_index = is-config[index].p_region_index1;
drc = is-config[index].drc;
 
drc-control.bypass = val;
 
-   if (!test_bit(PARAM_DRC_CONTROL, p_index))
-   fimc_is_set_param_bit(is, PARAM_DRC_CONTROL);
+   fimc_is_set_param_bit(is, PARAM_DRC_CONTROL);
 }
 
 void __is_set_fd_control(struct fimc_is *is, u32 val)
-- 
1.7.9.5

--
To 

[PATCH 1/2] v4l2-ctl: break down the streaming_set()

2013-04-10 Thread Tzu-Jung Lee
This patch breaks down the streaming_set() into smaller
ones, which can be resued for supporting m2m devices.

Further cleanup or consolidation can be applied with
separate patches, since this one tries not to modify
logics.

Signed-off-by: Tzu-Jung Lee tj...@ambarella.com
---
 utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 921 +++---
 1 file changed, 505 insertions(+), 416 deletions(-)

diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp 
b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
index c29565f..a180c6a 100644
--- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
@@ -26,8 +26,10 @@ static unsigned stream_count;
 static unsigned stream_skip;
 static unsigned stream_pat;
 static bool stream_loop;
-static unsigned reqbufs_count = 3;
-static char *file;
+static unsigned reqbufs_count_cap = 3;
+static unsigned reqbufs_count_out = 3;
+static char *file_cap;
+static char *file_out;
 
 #define NUM_PATTERNS (4)
 
@@ -198,21 +200,26 @@ void streaming_cmd(int ch, char *optarg)
stream_pat %= NUM_PATTERNS;
break;
case OptStreamTo:
-   file = optarg;
-   if (!strcmp(file, -))
+   file_cap = optarg;
+   if (!strcmp(file_cap, -))
options[OptSilent] = true;
break;
case OptStreamFrom:
-   file = optarg;
+   file_out = optarg;
break;
case OptStreamMmap:
case OptStreamUser:
+   if (optarg) {
+   reqbufs_count_cap = strtoul(optarg, 0L, 0);
+   if (reqbufs_count_cap == 0)
+   reqbufs_count_cap = 3;
+   }
case OptStreamOutMmap:
case OptStreamOutUser:
if (optarg) {
-   reqbufs_count = strtoul(optarg, 0L, 0);
-   if (reqbufs_count == 0)
-   reqbufs_count = 3;
+   reqbufs_count_out = strtoul(optarg, 0L, 0);
+   if (reqbufs_count_out == 0)
+   reqbufs_count_out = 3;
}
break;
}
@@ -526,475 +533,557 @@ static bool fill_buffer_from_file(void *buffers[], 
unsigned buffer_lengths[],
return true;
 }
 
-void streaming_set(int fd)
+static void do_setup_cap_buffers(int fd, struct v4l2_requestbuffers *reqbufs,
+bool is_mplane, unsigned *num_planes, bool 
is_mmap,
+void *buffers[], unsigned buffer_lengths[])
 {
-   if (options[OptStreamMmap] || options[OptStreamUser]) {
-   struct v4l2_requestbuffers reqbufs;
-   struct v4l2_event_subscription sub;
-   int fd_flags = fcntl(fd, F_GETFL);
-   bool is_mplane = capabilities 
-   (V4L2_CAP_VIDEO_CAPTURE_MPLANE |
-V4L2_CAP_VIDEO_M2M_MPLANE);
-   bool is_mmap = options[OptStreamMmap];
-   bool use_poll = options[OptStreamPoll];
-   __u32 type = is_mplane ?
-   V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE : 
V4L2_BUF_TYPE_VIDEO_CAPTURE;
-   FILE *fout = NULL;
-   unsigned num_planes = 1;
-
-   memset(reqbufs, 0, sizeof(reqbufs));
-   reqbufs.count = reqbufs_count;
-   reqbufs.type = type;
-   reqbufs.memory = is_mmap ? V4L2_MEMORY_MMAP : 
V4L2_MEMORY_USERPTR;
-   memset(sub, 0, sizeof(sub));
-   sub.type = V4L2_EVENT_EOS;
-   ioctl(fd, VIDIOC_SUBSCRIBE_EVENT, sub);
-
-   if (file) {
-   if (!strcmp(file, -))
-   fout = stdout;
-   else
-   fout = fopen(file, w+);
-   }
+   for (unsigned i = 0; i  reqbufs-count; i++) {
+   struct v4l2_plane planes[VIDEO_MAX_PLANES];
+   struct v4l2_buffer buf;
 
-   if (doioctl(fd, VIDIOC_REQBUFS, reqbufs))
+   memset(buf, 0, sizeof(buf));
+   memset(planes, 0, sizeof(planes));
+   buf.type = reqbufs-type;
+   buf.memory = reqbufs-memory;
+   buf.index = i;
+   if (is_mplane) {
+   buf.m.planes = planes;
+   buf.length = VIDEO_MAX_PLANES;
+   }
+   if (doioctl(fd, VIDIOC_QUERYBUF, buf))
return;
 
-   void *buffers[reqbufs.count * VIDEO_MAX_PLANES];
-   unsigned buffer_lengths[reqbufs.count * VIDEO_MAX_PLANES];
-   
-   for (unsigned i = 0; i  reqbufs.count; i++) {
-   struct v4l2_plane planes[VIDEO_MAX_PLANES];
-   struct v4l2_buffer buf;
+   if (is_mplane) {
+   *num_planes = 

[PATCH 2/2] v4l2-ctl: initial attempt to support M2M device streaming

2013-04-10 Thread Tzu-Jung Lee
Signed-off-by: Tzu-Jung Lee tj...@ambarella.com
---
 utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 207 +-
 1 file changed, 206 insertions(+), 1 deletion(-)

diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp 
b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
index a180c6a..0d9553a 100644
--- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
@@ -774,6 +774,15 @@ static int do_handle_cap(int fd, struct 
v4l2_requestbuffers *reqbufs,
}
}
*count += 1;
+
+   /*
+* The stream_count and stream_skip does not apply to capture path of
+* M2M devices.  In that case, we skip them with an early return.
+*/
+   if ((capabilities  V4L2_CAP_VIDEO_M2M) ||
+   (capabilities  V4L2_CAP_VIDEO_M2M_MPLANE))
+   return 0;
+
if (stream_skip) {
stream_skip--;
return 0;
@@ -1075,12 +1084,208 @@ void streaming_set_out(int fd)
fclose(fin);
 }
 
+enum stream_type {
+   CAP,
+   OUT,
+};
+
+void streaming_set_m2m(int fd)
+{
+   int fd_flags = fcntl(fd, F_GETFL);
+   bool use_poll = options[OptStreamPoll];
+
+   bool is_mplane = capabilities  V4L2_CAP_VIDEO_M2M_MPLANE;
+   unsigned num_planes[2] = {1, 1};
+   bool is_mmap = options[OptStreamMmap];
+
+   __u32 type[2];
+   FILE *file[2] = {NULL, NULL};
+   struct v4l2_requestbuffers reqbufs[2];
+
+   if (!(capabilities  V4L2_CAP_VIDEO_M2M) 
+   !(capabilities  V4L2_CAP_VIDEO_M2M_MPLANE)) {
+   fprintf(stderr, unsupported stream type\n);
+   return;
+   }
+
+   type[CAP] = is_mplane ?
+   V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE : 
V4L2_BUF_TYPE_VIDEO_CAPTURE;
+
+   type[OUT] = is_mplane ?
+   V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE : V4L2_BUF_TYPE_VIDEO_OUTPUT;
+
+   memset(reqbufs, 0, sizeof(reqbufs));
+
+   reqbufs[CAP].count = reqbufs_count_cap;
+   reqbufs[CAP].type = type[CAP];
+   reqbufs[CAP].memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
+
+   reqbufs[OUT].count = reqbufs_count_out;
+   reqbufs[OUT].type = type[OUT];
+   reqbufs[OUT].memory = is_mmap ? V4L2_MEMORY_MMAP : V4L2_MEMORY_USERPTR;
+
+   struct v4l2_event_subscription sub;
+
+   memset(sub, 0, sizeof(sub));
+   sub.type = V4L2_EVENT_EOS;
+   ioctl(fd, VIDIOC_SUBSCRIBE_EVENT, sub);
+
+   if (file_cap) {
+   if (!strcmp(file_cap, -))
+   file[CAP] = stdout;
+   else
+   file[CAP] = fopen(file_cap, w+);
+   }
+
+   if (file_out) {
+   if (!strcmp(file_out, -))
+   file[OUT] = stdin;
+   else
+   file[OUT] = fopen(file_out, r);
+   }
+
+   if (doioctl(fd, VIDIOC_REQBUFS, reqbufs[CAP]) ||
+   doioctl(fd, VIDIOC_REQBUFS, reqbufs[OUT]))
+   return;
+
+   void *buffers_cap[reqbufs_count_cap * VIDEO_MAX_PLANES];
+   void *buffers_out[reqbufs_count_out * VIDEO_MAX_PLANES];
+   unsigned buffer_lengths_cap[reqbufs_count_cap * VIDEO_MAX_PLANES];
+   unsigned buffer_lengths_out[reqbufs_count_out * VIDEO_MAX_PLANES];
+
+   do_setup_cap_buffers(fd, reqbufs[CAP], is_mplane, num_planes[CAP],
+is_mmap, buffers_cap, buffer_lengths_cap);
+
+   do_setup_out_buffers(fd, reqbufs[OUT], is_mplane, num_planes[OUT],
+is_mmap, buffers_out, buffer_lengths_out,
+file[OUT]);
+
+   if (doioctl(fd, VIDIOC_STREAMON, type[CAP]) ||
+   doioctl(fd, VIDIOC_STREAMON, type[OUT]))
+   return;
+
+   if (use_poll)
+   fcntl(fd, F_SETFL, fd_flags | O_NONBLOCK);
+
+   unsigned count[2] = { 0, 0 };
+   unsigned last[2] = { 0, 0 };
+   struct timeval tv_last[2];
+
+   fd_set fds[3];
+   fd_set *rd_fds = fds[0]; /* for capture */
+   fd_set *ex_fds = fds[1]; /* for capture */
+   fd_set *wr_fds = fds[2]; /* for output */
+
+   while (rd_fds || wr_fds || ex_fds) {
+
+   int r;
+
+   if (use_poll) {
+   struct timeval tv;
+
+   /* Timeout. */
+   tv.tv_sec = 2;
+   tv.tv_usec = 0;
+
+   if (rd_fds) {
+   FD_ZERO(rd_fds);
+   FD_SET(fd, rd_fds);
+   }
+
+   if (ex_fds) {
+   FD_ZERO(ex_fds);
+   FD_SET(fd, ex_fds);
+   }
+
+   if (wr_fds) {
+   FD_ZERO(wr_fds);
+   FD_SET(fd, wr_fds);
+
+   }
+
+   r = select(fd + 1, rd_fds, wr_fds, ex_fds, tv);
+
+   if (r == -1) {

[REVIEW PATCH 0/2] dt3155v4l: Two fixes.

2013-04-10 Thread Hans Verkuil
This small patch series fixes two different bugs in dt3155v4l: it fixes a
mutex locking bug in the open() function and it switches the driver to the
monotonic clock (as all drivers should use).

I've tested this on actual hardware, and I hope to post more fixes for this
driver for 3.11. But I'd like to get these two fixes in for 3.10 since
especially the first bug makes the driver unusable.

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


[REVIEW PATCH 1/2] dt3155v4l: fix incorrect mutex locking.

2013-04-10 Thread Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com

A mutex_unlock was missing in the 'success' path of the open() call,
and also at one error path in the same function.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/staging/media/dt3155v4l/dt3155v4l.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c 
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 073b3b3..57fadea 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -398,7 +398,7 @@ dt3155_open(struct file *filp)
pd-field_count = 0;
ret = vb2_queue_init(pd-q);
if (ret  0)
-   return ret;
+   goto err_request_irq;
INIT_LIST_HEAD(pd-dmaq);
spin_lock_init(pd-lock);
/* disable all irqs, clear all irq flags */
@@ -410,6 +410,7 @@ dt3155_open(struct file *filp)
goto err_request_irq;
}
pd-users++;
+   mutex_unlock(pd-mux);
return 0; /* success */
 err_request_irq:
kfree(pd-q);
-- 
1.7.10.4

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


[REVIEW PATCH 2/2] dt3155v4l: fix timestamp handling.

2013-04-10 Thread Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com

Use the monotonic clock and set the timestamp_type that vb2 expects.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/staging/media/dt3155v4l/dt3155v4l.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c 
b/drivers/staging/media/dt3155v4l/dt3155v4l.c
index 57fadea..c32e0ac 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -26,6 +26,7 @@
 #include linux/slab.h
 #include media/v4l2-dev.h
 #include media/v4l2-ioctl.h
+#include media/v4l2-common.h
 #include media/videobuf2-dma-contig.h
 
 #include dt3155v4l.h
@@ -341,7 +342,7 @@ dt3155_irq_handler_even(int irq, void *dev_id)
 
spin_lock(ipd-lock);
if (ipd-curr_buf) {
-   do_gettimeofday(ipd-curr_buf-v4l2_buf.timestamp);
+   v4l2_get_timestamp(ipd-curr_buf-v4l2_buf.timestamp);
ipd-curr_buf-v4l2_buf.sequence = (ipd-field_count)  1;
vb2_buffer_done(ipd-curr_buf, VB2_BUF_STATE_DONE);
}
@@ -390,6 +391,7 @@ dt3155_open(struct file *filp)
goto err_alloc_queue;
}
pd-q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   pd-q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
pd-q-io_modes = VB2_READ | VB2_MMAP;
pd-q-ops = q_ops;
pd-q-mem_ops = vb2_dma_contig_memops;
-- 
1.7.10.4

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


Re: [media] redrat3: remove memcpys and fix unaligned memory access

2013-04-10 Thread Sean Young
On Tue, Apr 09, 2013 at 12:02:59PM +0300, Dan Carpenter wrote:
 I had a question about 4c055a5ae94c: [media] redrat3: remove memcpys
 and fix unaligned memory access from Feb 16, 2013.
 
 drivers/media/rc/redrat3.c
619  /* grab the Length and type of transfer */
620  pktlen = be16_to_cpu(header-length);
621  pkttype = be16_to_cpu(header-transfer_type);
622  
623  if (pktlen  sizeof(rr3-irdata)) {
624  dev_warn(rr3-dev, packet length %u too large\n, 
 pktlen);
625  return;
626  }
627  
628  switch (pkttype) {
629  case RR3_ERROR:
630  if (len = sizeof(struct redrat3_error)) {
631  struct redrat3_error *error = 
 rr3-bulk_in_buf;
632  unsigned fw_error = 
 be16_to_cpu(error-fw_error);
633  redrat3_dump_fw_error(rr3, fw_error);
634  }
635  break;
636  
637  case RR3_MOD_SIGNAL_IN:
638  memcpy(rr3-irdata, rr3-bulk_in_buf, len);
^^^
639  rr3-bytes_read = len;
   ^^^
640  rr3_dbg(rr3-dev, bytes_read %d, pktlen %d\n,
641  rr3-bytes_read, pktlen);
  ^^
 Should we be copying pktlen bytes on the line before?  It seems
 inconsistent that it doesn't match the debug code.

The pktlen is the length of the entire packet, and here we might have
received only part of it. This debug line would have been better if
it was:

rr3_dbg(rr3-dev, %s read of total %d\n, len, pktlen);

 My main concern is that we limit the size of pktlen but then we only
 use it for debug output.

pktlen is a copy of the length field of the packet. That gets memcpy'd
(line 638) into rr3-irdata where it is available as rr3-irdata.length. 
It is later used to check if we've received the full packet:

 689 if (rr3-bytes_read  be16_to_cpu(rr3-irdata.header.length))
 690 /* we're still accumulating data */
 691 return 0;

HTH and thanks for checking my changes.

Sean
--
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] radio-si476x: check different function pointers

2013-04-10 Thread Dan Carpenter
This is a static checker where it complains if we check for one function
pointer and then call a different function on the next line.

In most cases, the code does the same thing before and after this patch.
For example, when -phase_diversity is non-NULL then -phase_div_status
is also non-NULL.

The one place where that's not true is when we check -rds_blckcnt
instead of -rsq_status.  In those cases, we would want to call
-rsq_status but we instead return -ENOENT.

Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Please review this carefully.  I don't have the hardware to test it.

diff --git a/drivers/media/radio/radio-si476x.c 
b/drivers/media/radio/radio-si476x.c
index 9430c6a..817fc0c 100644
--- a/drivers/media/radio/radio-si476x.c
+++ b/drivers/media/radio/radio-si476x.c
@@ -854,7 +854,7 @@ static int si476x_radio_g_volatile_ctrl(struct v4l2_ctrl 
*ctrl)
switch (ctrl-id) {
case V4L2_CID_SI476X_INTERCHIP_LINK:
if (si476x_core_has_diversity(radio-core)) {
-   if (radio-ops-phase_diversity) {
+   if (radio-ops-phase_div_status) {
retval = 
radio-ops-phase_div_status(radio-core);
if (retval  0)
break;
@@ -1285,7 +1285,7 @@ static ssize_t si476x_radio_read_agc_blob(struct file 
*file,
struct si476x_agc_status_report report;
 
si476x_core_lock(radio-core);
-   if (radio-ops-rds_blckcnt)
+   if (radio-ops-agc_status)
err = radio-ops-agc_status(radio-core, report);
else
err = -ENOENT;
@@ -1320,7 +1320,7 @@ static ssize_t si476x_radio_read_rsq_blob(struct file 
*file,
};
 
si476x_core_lock(radio-core);
-   if (radio-ops-rds_blckcnt)
+   if (radio-ops-rsq_status)
err = radio-ops-rsq_status(radio-core, args, report);
else
err = -ENOENT;
@@ -1355,7 +1355,7 @@ static ssize_t si476x_radio_read_rsq_primary_blob(struct 
file *file,
};
 
si476x_core_lock(radio-core);
-   if (radio-ops-rds_blckcnt)
+   if (radio-ops-rsq_status)
err = radio-ops-rsq_status(radio-core, args, report);
else
err = -ENOENT;
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Guennadi Liakhovetski
Hi Barry

On Wed, 10 Apr 2013, Barry Song wrote:

 Hi Guennadia,
 
 2012/9/27 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  Currently soc-camera doesn't work with independently registered I2C client
  devices, it has to register them itself. This patch adds support for such
  configurations, in which case client drivers have to request deferred
  probing until their host becomes available and enables the data interface.
 
  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
 
 it seems deferred probing for i2c camera sensors is a more workaround
 than a solution.
 currently,  soc-camera-pdrv is the manager of the whole initilization
 flow. it all requires the host/client registerred and initilized
 synchronously. so that results in strange things like that we fill a
 i2c_board_info structure in arch/arm/mach-xxx but we never call
 anything like i2c_new_device() to add the i2c client in mach. because
 we need to do that in the soc-camera-pdrv driver to make all things
 happen orderly.
 
 but now after we move to DT, all i2c device will be registerred
 automatically by of_i2c_register_devices() in i2c_host 's probe, that
 makes the problem much worse and very urgent to get fixed.
 
 returning DEFERRED_PROBE error until getting the private data filled
 by the manager,

This hasn't been the case since several versions of these patches. We no 
longer use private data to decide whether subdevices can probe 
successfully or have to defer probing.

 indirectly, makes the things seem to be asynchronous,
 but essentially it is still synchronous because the overall timing
 line is still controller by soc-camera-pdrv.

It isn't. If your subdevice driver doesn't have any dependencies, like 
e.g. sh_mobile_csi2.c, it will probe asynchronously whenever it's loaded. 
It is the task of a bridge driver, in our case of the soc-camera core, to 
register notifiers and a list of expected subdevices with the v4l2-async 
subsystem. As subdevices complete their probing they signal that to the 
v4l2-async too, which then calls bridge's notifiers, which then can build 
the pipeline.

 what about another possible way:
 we let all host and i2c client driver probed in any order,

This cannot work, because some I2C devices, e.g. sensors, need a clock 
signal from the camera interface to probe. Before the bridge driver has 
completed its probing and registered a suitable clock source with the 
v4l2-clk framework, sensors cannot be probed. And no, we don't want to 
fake successful probing without actually being able to talk to the 
hardware.

Thanks
Guennadi

 but let the
 final soc-camera-pdrv is the connection of all things. the situation
 of soc_camera is very similar with ALSA SoC. it turns out ASoC has
 done that very well.
 
 -barry
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Barry Song
Hi Guennadia,
Thanks!

2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 Hi Barry

 On Wed, 10 Apr 2013, Barry Song wrote:

 Hi Guennadia,

 2012/9/27 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  Currently soc-camera doesn't work with independently registered I2C client
  devices, it has to register them itself. This patch adds support for such
  configurations, in which case client drivers have to request deferred
  probing until their host becomes available and enables the data interface.
 
  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---

 it seems deferred probing for i2c camera sensors is a more workaround
 than a solution.
 currently,  soc-camera-pdrv is the manager of the whole initilization
 flow. it all requires the host/client registerred and initilized
 synchronously. so that results in strange things like that we fill a
 i2c_board_info structure in arch/arm/mach-xxx but we never call
 anything like i2c_new_device() to add the i2c client in mach. because
 we need to do that in the soc-camera-pdrv driver to make all things
 happen orderly.

 but now after we move to DT, all i2c device will be registerred
 automatically by of_i2c_register_devices() in i2c_host 's probe, that
 makes the problem much worse and very urgent to get fixed.

 returning DEFERRED_PROBE error until getting the private data filled
 by the manager,

 This hasn't been the case since several versions of these patches. We no
 longer use private data to decide whether subdevices can probe
 successfully or have to defer probing.

sorry for missing.  i will refer to your newer versions.


 indirectly, makes the things seem to be asynchronous,
 but essentially it is still synchronous because the overall timing
 line is still controller by soc-camera-pdrv.

 It isn't. If your subdevice driver doesn't have any dependencies, like
 e.g. sh_mobile_csi2.c, it will probe asynchronously whenever it's loaded.
 It is the task of a bridge driver, in our case of the soc-camera core, to
 register notifiers and a list of expected subdevices with the v4l2-async
 subsystem. As subdevices complete their probing they signal that to the
 v4l2-async too, which then calls bridge's notifiers, which then can build
 the pipeline.

it seems we didn't describle my idea clearly in the last mail. i
actually mean we don't need that if we put the pipeline building to
the last stage after all things have been placed there.


 what about another possible way:
 we let all host and i2c client driver probed in any order,

 This cannot work, because some I2C devices, e.g. sensors, need a clock
 signal from the camera interface to probe. Before the bridge driver has
 completed its probing and registered a suitable clock source with the
 v4l2-clk framework, sensors cannot be probed. And no, we don't want to
 fake successful probing without actually being able to talk to the
 hardware.

i'd say same dependency also exists on ASoC.  a fake successful
probing doesn't mean it should really begin to work if there is no
external trigger source.  ASoC has successfully done that by a machine
driver to connect all DAI.
a way is we put all things ready in their places, finally we connect
them together and launch the whole hardware flow.

anyway, if you have maken the things work by some simple hacking and
that means minimial changes to current soc-camera, i think we can
follow.


 Thanks
 Guennadi

 but let the
 final soc-camera-pdrv is the connection of all things. the situation
 of soc_camera is very similar with ALSA SoC. it turns out ASoC has
 done that very well.


-barry
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Mark Brown
On Wed, Apr 10, 2013 at 09:53:20PM +0800, Barry Song wrote:
 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:

  what about another possible way:
  we let all host and i2c client driver probed in any order,

  This cannot work, because some I2C devices, e.g. sensors, need a clock
  signal from the camera interface to probe. Before the bridge driver has
  completed its probing and registered a suitable clock source with the
  v4l2-clk framework, sensors cannot be probed. And no, we don't want to
  fake successful probing without actually being able to talk to the
  hardware.

 i'd say same dependency also exists on ASoC.  a fake successful
 probing doesn't mean it should really begin to work if there is no
 external trigger source.  ASoC has successfully done that by a machine
 driver to connect all DAI.
 a way is we put all things ready in their places, finally we connect
 them together and launch the whole hardware flow.

In the ASoC case the idea is that drivers should probe as far as they
can with just the chip and then register with the core.  The machine
driver defers probing until all components have probed and then runs
through second stage initialisaton which pulls everything together.


signature.asc
Description: Digital signature


Re: [PATCH 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Barry Song
2013/4/10 Mark Brown broo...@opensource.wolfsonmicro.com:
 On Wed, Apr 10, 2013 at 09:53:20PM +0800, Barry Song wrote:
 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:

  what about another possible way:
  we let all host and i2c client driver probed in any order,

  This cannot work, because some I2C devices, e.g. sensors, need a clock
  signal from the camera interface to probe. Before the bridge driver has
  completed its probing and registered a suitable clock source with the
  v4l2-clk framework, sensors cannot be probed. And no, we don't want to
  fake successful probing without actually being able to talk to the
  hardware.

 i'd say same dependency also exists on ASoC.  a fake successful
 probing doesn't mean it should really begin to work if there is no
 external trigger source.  ASoC has successfully done that by a machine
 driver to connect all DAI.
 a way is we put all things ready in their places, finally we connect
 them together and launch the whole hardware flow.

 In the ASoC case the idea is that drivers should probe as far as they
 can with just the chip and then register with the core.  The machine
 driver defers probing until all components have probed and then runs
 through second stage initialisaton which pulls everything together.

yes. thanks for clarification, Mark. that is really what i want in
soc-camera too.
put all things in their places, and the final connector wait for
everyone and put them in the initialized status.

-barry
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Guennadi Liakhovetski
On Wed, 10 Apr 2013, Barry Song wrote:

 Hi Guennadia,

There's a typo above.

 Thanks!
 
 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  Hi Barry
 
  On Wed, 10 Apr 2013, Barry Song wrote:
 
  Hi Guennadia,
 
  2012/9/27 Guennadi Liakhovetski g.liakhovet...@gmx.de:
   Currently soc-camera doesn't work with independently registered I2C 
   client
   devices, it has to register them itself. This patch adds support for such
   configurations, in which case client drivers have to request deferred
   probing until their host becomes available and enables the data 
   interface.
  
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
 
  it seems deferred probing for i2c camera sensors is a more workaround
  than a solution.
  currently,  soc-camera-pdrv is the manager of the whole initilization
  flow. it all requires the host/client registerred and initilized
  synchronously. so that results in strange things like that we fill a
  i2c_board_info structure in arch/arm/mach-xxx but we never call
  anything like i2c_new_device() to add the i2c client in mach. because
  we need to do that in the soc-camera-pdrv driver to make all things
  happen orderly.
 
  but now after we move to DT, all i2c device will be registerred
  automatically by of_i2c_register_devices() in i2c_host 's probe, that
  makes the problem much worse and very urgent to get fixed.
 
  returning DEFERRED_PROBE error until getting the private data filled
  by the manager,
 
  This hasn't been the case since several versions of these patches. We no
  longer use private data to decide whether subdevices can probe
  successfully or have to defer probing.
 
 sorry for missing.  i will refer to your newer versions.
 
 
  indirectly, makes the things seem to be asynchronous,
  but essentially it is still synchronous because the overall timing
  line is still controller by soc-camera-pdrv.
 
  It isn't. If your subdevice driver doesn't have any dependencies, like
  e.g. sh_mobile_csi2.c, it will probe asynchronously whenever it's loaded.
  It is the task of a bridge driver, in our case of the soc-camera core, to
  register notifiers and a list of expected subdevices with the v4l2-async
  subsystem. As subdevices complete their probing they signal that to the
  v4l2-async too, which then calls bridge's notifiers, which then can build
  the pipeline.
 
 it seems we didn't describle my idea clearly in the last mail. i
 actually mean we don't need that if we put the pipeline building to
 the last stage after all things have been placed there.
 
 
  what about another possible way:
  we let all host and i2c client driver probed in any order,
 
  This cannot work, because some I2C devices, e.g. sensors, need a clock
  signal from the camera interface to probe. Before the bridge driver has
  completed its probing and registered a suitable clock source with the
  v4l2-clk framework, sensors cannot be probed. And no, we don't want to
  fake successful probing without actually being able to talk to the
  hardware.
 
 i'd say same dependency also exists on ASoC.  a fake successful
 probing doesn't mean it should really begin to work if there is no
 external trigger source.  ASoC has successfully done that by a machine
 driver to connect all DAI.
 a way is we put all things ready in their places, finally we connect
 them together and launch the whole hardware flow.
 
 anyway, if you have maken the things work by some simple hacking and
 that means minimial changes to current soc-camera, i think we can
 follow.

If you want to volunteer to step up as a new soc-camera maintainer to 
replace my simple hacking with your comprehencive and advanced designs - 
feel free, I'll ack straight away.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Barry Song
2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 On Wed, 10 Apr 2013, Barry Song wrote:

 Hi Guennadi,

 There's a typo above.

sorry for the typo.


 Thanks!

 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  Hi Barry
 
  On Wed, 10 Apr 2013, Barry Song wrote:
 
  Hi Guennadia,
 
  2012/9/27 Guennadi Liakhovetski g.liakhovet...@gmx.de:
   Currently soc-camera doesn't work with independently registered I2C 
   client
   devices, it has to register them itself. This patch adds support for 
   such
   configurations, in which case client drivers have to request deferred
   probing until their host becomes available and enables the data 
   interface.
  
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
 
  it seems deferred probing for i2c camera sensors is a more workaround
  than a solution.
  currently,  soc-camera-pdrv is the manager of the whole initilization
  flow. it all requires the host/client registerred and initilized
  synchronously. so that results in strange things like that we fill a
  i2c_board_info structure in arch/arm/mach-xxx but we never call
  anything like i2c_new_device() to add the i2c client in mach. because
  we need to do that in the soc-camera-pdrv driver to make all things
  happen orderly.
 
  but now after we move to DT, all i2c device will be registerred
  automatically by of_i2c_register_devices() in i2c_host 's probe, that
  makes the problem much worse and very urgent to get fixed.
 
  returning DEFERRED_PROBE error until getting the private data filled
  by the manager,
 
  This hasn't been the case since several versions of these patches. We no
  longer use private data to decide whether subdevices can probe
  successfully or have to defer probing.

 sorry for missing.  i will refer to your newer versions.

 
  indirectly, makes the things seem to be asynchronous,
  but essentially it is still synchronous because the overall timing
  line is still controller by soc-camera-pdrv.
 
  It isn't. If your subdevice driver doesn't have any dependencies, like
  e.g. sh_mobile_csi2.c, it will probe asynchronously whenever it's loaded.
  It is the task of a bridge driver, in our case of the soc-camera core, to
  register notifiers and a list of expected subdevices with the v4l2-async
  subsystem. As subdevices complete their probing they signal that to the
  v4l2-async too, which then calls bridge's notifiers, which then can build
  the pipeline.

 it seems we didn't describle my idea clearly in the last mail. i
 actually mean we don't need that if we put the pipeline building to
 the last stage after all things have been placed there.

 
  what about another possible way:
  we let all host and i2c client driver probed in any order,
 
  This cannot work, because some I2C devices, e.g. sensors, need a clock
  signal from the camera interface to probe. Before the bridge driver has
  completed its probing and registered a suitable clock source with the
  v4l2-clk framework, sensors cannot be probed. And no, we don't want to
  fake successful probing without actually being able to talk to the
  hardware.

 i'd say same dependency also exists on ASoC.  a fake successful
 probing doesn't mean it should really begin to work if there is no
 external trigger source.  ASoC has successfully done that by a machine
 driver to connect all DAI.
 a way is we put all things ready in their places, finally we connect
 them together and launch the whole hardware flow.

 anyway, if you have maken the things work by some simple hacking and
 that means minimial changes to current soc-camera, i think we can
 follow.

 If you want to volunteer to step up as a new soc-camera maintainer to
 replace my simple hacking with your comprehencive and advanced designs -
 feel free, I'll ack straight away.

i am not sure whether you agree the new way or not. if you also agree
this is a better way, i think we can do something to move ahead. i
need sync and get input from you expert :-)


 Thanks
 Guennadi

-barry
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Guennadi Liakhovetski
On Wed, 10 Apr 2013, Barry Song wrote:

 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  On Wed, 10 Apr 2013, Barry Song wrote:

[snip]

   This cannot work, because some I2C devices, e.g. sensors, need a clock
   signal from the camera interface to probe. Before the bridge driver has
   completed its probing and registered a suitable clock source with the
   v4l2-clk framework, sensors cannot be probed. And no, we don't want to
   fake successful probing without actually being able to talk to the
   hardware.
 
  i'd say same dependency also exists on ASoC.  a fake successful
  probing doesn't mean it should really begin to work if there is no
  external trigger source.  ASoC has successfully done that by a machine
  driver to connect all DAI.
  a way is we put all things ready in their places, finally we connect
  them together and launch the whole hardware flow.
 
  anyway, if you have maken the things work by some simple hacking and
  that means minimial changes to current soc-camera, i think we can
  follow.
 
  If you want to volunteer to step up as a new soc-camera maintainer to
  replace my simple hacking with your comprehencive and advanced designs -
  feel free, I'll ack straight away.
 
 i am not sure whether you agree the new way or not. if you also agree
 this is a better way,

In fact I don't.

 i think we can do something to move ahead. i
 need sync and get input from you expert :-)

I suggest you read all the mailing list discussions of these topics over 
last months / years, conference discussion protocols instead of restarting 
a beaten to death topic at the v8 time-frame.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 07/14] media: soc-camera: support deferred probing of clients

2013-04-10 Thread Barry Song
2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
 On Wed, 10 Apr 2013, Barry Song wrote:

 2013/4/10 Guennadi Liakhovetski g.liakhovet...@gmx.de:
  On Wed, 10 Apr 2013, Barry Song wrote:

 [snip]

   This cannot work, because some I2C devices, e.g. sensors, need a clock
   signal from the camera interface to probe. Before the bridge driver has
   completed its probing and registered a suitable clock source with the
   v4l2-clk framework, sensors cannot be probed. And no, we don't want to
   fake successful probing without actually being able to talk to the
   hardware.
 
  i'd say same dependency also exists on ASoC.  a fake successful
  probing doesn't mean it should really begin to work if there is no
  external trigger source.  ASoC has successfully done that by a machine
  driver to connect all DAI.
  a way is we put all things ready in their places, finally we connect
  them together and launch the whole hardware flow.
 
  anyway, if you have maken the things work by some simple hacking and
  that means minimial changes to current soc-camera, i think we can
  follow.
 
  If you want to volunteer to step up as a new soc-camera maintainer to
  replace my simple hacking with your comprehencive and advanced designs -
  feel free, I'll ack straight away.

 i am not sure whether you agree the new way or not. if you also agree
 this is a better way,

 In fact I don't.

 i think we can do something to move ahead. i
 need sync and get input from you expert :-)

 I suggest you read all the mailing list discussions of these topics over
 last months / years, conference discussion protocols instead of restarting
 a beaten to death topic at the v8 time-frame.

you think it has been dead but i think it is still alive since there
are still sombody like me starting a beaten for that.
anyway,  it doesn't really matter too much.
i can definitely follow what you like as you have succefully built a
good soc-camera system.


 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/

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


[REVIEWv2 PATCH 12/12] hdpvr: allow g/s_std when in legacy mode.

2013-04-10 Thread Hans Verkuil
Leo, can you verify that this works for you as well? I tested it without
problems with MythTV and gstreamer.

Thanks!

Hans

Both MythTV and gstreamer expect that they can set/get/query/enumerate the
standards, even if the input is the component input for which standards
really do not apply.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/usb/hdpvr/hdpvr-video.c |   40 -
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c 
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 4376309..38724d7 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -571,13 +571,14 @@ static int vidioc_querycap(struct file *file, void  *priv,
return 0;
 }
 
-static int vidioc_s_std(struct file *file, void *private_data,
+static int vidioc_s_std(struct file *file, void *_fh,
v4l2_std_id std)
 {
struct hdpvr_device *dev = video_drvdata(file);
+   struct hdpvr_fh *fh = _fh;
u8 std_type = 1;
 
-   if (dev-options.video_input == HDPVR_COMPONENT)
+   if (!fh-legacy_mode  dev-options.video_input == HDPVR_COMPONENT)
return -ENODATA;
if (dev-status != STATUS_IDLE)
return -EBUSY;
@@ -590,25 +591,27 @@ static int vidioc_s_std(struct file *file, void 
*private_data,
return hdpvr_config_call(dev, CTRL_VIDEO_STD_TYPE, std_type);
 }
 
-static int vidioc_g_std(struct file *file, void *private_data,
+static int vidioc_g_std(struct file *file, void *_fh,
v4l2_std_id *std)
 {
struct hdpvr_device *dev = video_drvdata(file);
+   struct hdpvr_fh *fh = _fh;
 
-   if (dev-options.video_input == HDPVR_COMPONENT)
+   if (!fh-legacy_mode  dev-options.video_input == HDPVR_COMPONENT)
return -ENODATA;
*std = dev-cur_std;
return 0;
 }
 
-static int vidioc_querystd(struct file *file, void *fh, v4l2_std_id *a)
+static int vidioc_querystd(struct file *file, void *_fh, v4l2_std_id *a)
 {
struct hdpvr_device *dev = video_drvdata(file);
struct hdpvr_video_info *vid_info;
+   struct hdpvr_fh *fh = _fh;
 
-   if (dev-options.video_input == HDPVR_COMPONENT)
-   return -ENODATA;
*a = V4L2_STD_ALL;
+   if (dev-options.video_input == HDPVR_COMPONENT)
+   return fh-legacy_mode ? 0 : -ENODATA;
vid_info = get_video_info(dev);
if (vid_info == NULL)
return 0;
@@ -742,9 +745,9 @@ static const char *iname[] = {
[HDPVR_COMPOSITE] = Composite,
 };
 
-static int vidioc_enum_input(struct file *file, void *priv,
-   struct v4l2_input *i)
+static int vidioc_enum_input(struct file *file, void *_fh, struct v4l2_input 
*i)
 {
+   struct hdpvr_fh *fh = _fh;
unsigned int n;
 
n = i-index;
@@ -758,13 +761,15 @@ static int vidioc_enum_input(struct file *file, void 
*priv,
 
i-audioset = 1HDPVR_RCA_FRONT | 1HDPVR_RCA_BACK | 1HDPVR_SPDIF;
 
+   if (fh-legacy_mode)
+   n = 1;
i-capabilities = n ? V4L2_IN_CAP_STD : V4L2_IN_CAP_DV_TIMINGS;
i-std = n ? V4L2_STD_ALL : 0;
 
return 0;
 }
 
-static int vidioc_s_input(struct file *file, void *private_data,
+static int vidioc_s_input(struct file *file, void *_fh,
  unsigned int index)
 {
struct hdpvr_device *dev = video_drvdata(file);
@@ -779,8 +784,20 @@ static int vidioc_s_input(struct file *file, void 
*private_data,
retval = hdpvr_config_call(dev, CTRL_VIDEO_INPUT_VALUE, index+1);
if (!retval) {
dev-options.video_input = index;
+   /*
+* Unfortunately gstreamer calls ENUMSTD and bails out if it
+* won't find any formats, even though component input is
+* selected. This means that we have to leave tvnorms at
+* V4L2_STD_ALL. We cannot use the 'legacy' trick since
+* tvnorms is set at the device node level and not at the
+* filehandle level.
+*
+* Comment this out for now, but if the legacy mode can be
+* removed in the future, then this code should be enabled
+* again.
dev-video_dev-tvnorms =
-   index != HDPVR_COMPONENT ? V4L2_STD_ALL : 0;
+   (index != HDPVR_COMPONENT) ? V4L2_STD_ALL : 0;
+*/
}
 
return retval;
@@ -1126,6 +1143,7 @@ static const struct video_device hdpvr_video_template = {
.fops   = hdpvr_fops,
.release= hdpvr_device_release,
.ioctl_ops  = hdpvr_ioctl_ops,
+   .tvnorms= V4L2_STD_ALL,
 };
 
 static const struct v4l2_ctrl_ops hdpvr_ctrl_ops = {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line 

Re: [REVIEWv2 PATCH 12/12] hdpvr: allow g/s_std when in legacy mode.

2013-04-10 Thread Hans Verkuil
On Wed April 10 2013 18:27:43 Hans Verkuil wrote:
 Leo, can you verify that this works for you as well? I tested it without
 problems with MythTV and gstreamer.
 
 Thanks!
 
   Hans
 
 Both MythTV and gstreamer expect that they can set/get/query/enumerate the
 standards, even if the input is the component input for which standards
 really do not apply.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/usb/hdpvr/hdpvr-video.c |   40 
 -
  1 file changed, 29 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c 
 b/drivers/media/usb/hdpvr/hdpvr-video.c
 index 4376309..38724d7 100644
 --- a/drivers/media/usb/hdpvr/hdpvr-video.c
 +++ b/drivers/media/usb/hdpvr/hdpvr-video.c


 -static int vidioc_enum_input(struct file *file, void *priv,
 - struct v4l2_input *i)
 +static int vidioc_enum_input(struct file *file, void *_fh, struct v4l2_input 
 *i)
  {
 + struct hdpvr_fh *fh = _fh;
   unsigned int n;
  
   n = i-index;
 @@ -758,13 +761,15 @@ static int vidioc_enum_input(struct file *file, void 
 *priv,
  
   i-audioset = 1HDPVR_RCA_FRONT | 1HDPVR_RCA_BACK | 1HDPVR_SPDIF;
  
 + if (fh-legacy_mode)
 + n = 1;

Oops, these two lines should be removed. Otherwise non-legacy apps like qv4l2 
will
break as they rely on accurate capability reporting.

   i-capabilities = n ? V4L2_IN_CAP_STD : V4L2_IN_CAP_DV_TIMINGS;
   i-std = n ? V4L2_STD_ALL : 0;
  
   return 0;
  }

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


cron job: media_tree daily build: WARNINGS

2013-04-10 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 10 19:00:17 CEST 2013
git branch: test
git hash:   81e096c8ac6a064854c2157e0bf802dc4906678c
gcc version:i686-linux-gcc (GCC) 4.7.2
host hardware:  x86_64
host os:3.8-3.slh.2-amd64

linux-git-arm-davinci: OK
linux-git-arm-exynos: WARNINGS
linux-git-arm-omap: WARNINGS
linux-git-blackfin: WARNINGS
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: WARNINGS
linux-2.6.32.27-i686: WARNINGS
linux-2.6.33.7-i686: WARNINGS
linux-2.6.34.7-i686: WARNINGS
linux-2.6.35.9-i686: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: OK
linux-3.9-rc1-i686: OK
linux-2.6.31.14-x86_64: WARNINGS
linux-2.6.32.27-x86_64: WARNINGS
linux-2.6.33.7-x86_64: WARNINGS
linux-2.6.34.7-x86_64: WARNINGS
linux-2.6.35.9-x86_64: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
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


[PATCH] drivers: media: platform: convert to devm_ioremap_resource()

2013-04-10 Thread Silviu-Mihai Popescu
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.

Signed-off-by: Silviu-Mihai Popescu silviupopescu1...@gmail.com
---
 drivers/media/platform/sh_veu.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c
index cb54c69..911f562 100644
--- a/drivers/media/platform/sh_veu.c
+++ b/drivers/media/platform/sh_veu.c
@@ -1164,9 +1164,9 @@ static int sh_veu_probe(struct platform_device *pdev)
 
veu-is_2h = resource_size(reg_res) == 0x22c;
 
-   veu-base = devm_request_and_ioremap(pdev-dev, reg_res);
-   if (!veu-base)
-   return -ENOMEM;
+   veu-base = devm_ioremap_resource(pdev-dev, reg_res);
+   if (IS_ERR(veu-base))
+   return PTR_ERR(veu-base);
 
ret = devm_request_threaded_irq(pdev-dev, irq, sh_veu_isr, sh_veu_bh,
0, veu, veu);
-- 
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] solo6x10: Approximate frame intervals with non-standard denominator

2013-04-10 Thread Ismael Luceno
Instead of falling back to 1/25 (PAL) or 1/30 (NTSC).

Signed-off-by: Ismael Luceno ismael.luc...@corp.bluecherry.net

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch media
# Changes to be committed:
#   (use git reset HEAD file... to unstage)
#
#   modified:   drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
#
# Untracked files:
#   (use git add file... to include in what will be committed)
#
#   buildtest/
---
 drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 38 +-
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c 
b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
index 6c7d20f..6965307 100644
--- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
@@ -975,12 +975,11 @@ static int solo_g_parm(struct file *file, void *priv,
   struct v4l2_streamparm *sp)
 {
struct solo_enc_dev *solo_enc = video_drvdata(file);
-   struct solo_dev *solo_dev = solo_enc-solo_dev;
struct v4l2_captureparm *cp = sp-parm.capture;
 
cp-capability = V4L2_CAP_TIMEPERFRAME;
cp-timeperframe.numerator = solo_enc-interval;
-   cp-timeperframe.denominator = solo_dev-fps;
+   cp-timeperframe.denominator = solo_enc-solo_dev-fps;
cp-capturemode = 0;
/* XXX: Shouldn't we be able to get/set this from videobuf? */
cp-readbuffers = 2;
@@ -988,36 +987,29 @@ static int solo_g_parm(struct file *file, void *priv,
return 0;
 }
 
+static inline int calc_interval(u8 fps, u32 n, u32 d)
+{
+   if (unlikely(!n || !d))
+   return 1;
+   if (likely(d == fps))
+   return n;
+   n *= fps;
+   return min(15U, n / d + (n % d = (fps  1)));
+}
+
 static int solo_s_parm(struct file *file, void *priv,
   struct v4l2_streamparm *sp)
 {
struct solo_enc_dev *solo_enc = video_drvdata(file);
-   struct solo_dev *solo_dev = solo_enc-solo_dev;
-   struct v4l2_captureparm *cp = sp-parm.capture;
+   struct v4l2_fract *t = sp-parm.capture.timeperframe;
+   u8 fps = solo_enc-solo_dev-fps;
 
if (vb2_is_streaming(solo_enc-vidq))
return -EBUSY;
 
-   if ((cp-timeperframe.numerator == 0) ||
-   (cp-timeperframe.denominator == 0)) {
-   /* reset framerate */
-   cp-timeperframe.numerator = 1;
-   cp-timeperframe.denominator = solo_dev-fps;
-   }
-
-   if (cp-timeperframe.denominator != solo_dev-fps)
-   cp-timeperframe.denominator = solo_dev-fps;
-
-   if (cp-timeperframe.numerator  15)
-   cp-timeperframe.numerator = 15;
-
-   solo_enc-interval = cp-timeperframe.numerator;
-
-   cp-capability = V4L2_CAP_TIMEPERFRAME;
-   cp-readbuffers = 2;
-
+   solo_enc-interval = calc_interval(fps, t-numerator, t-denominator);
solo_update_mode(solo_enc);
-   return 0;
+   return solo_g_parm(file, priv, sp);
 }
 
 static long solo_enc_default(struct file *file, void *fh,
-- 
1.8.2

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


Re: linux-next: Tree for Apr 10 (meda and OF)

2013-04-10 Thread Randy Dunlap
On 04/10/13 01:48, Stephen Rothwell wrote:
 Hi all,
 
 Changes since 20130409:
 


on i386:

ERROR: of_get_next_parent [drivers/media/v4l2-core/videodev.ko] undefined!


'of_get_next_parent()' should be exported for use by modules...?


-- 
~Randy
--
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: linux-next: Tree for Apr 10 (media and OF)

2013-04-10 Thread Sylwester Nawrocki

On 04/10/2013 11:36 PM, Randy Dunlap wrote:

On 04/10/13 01:48, Stephen Rothwell wrote:

Hi all,

Changes since 20130409:




on i386:

ERROR: of_get_next_parent [drivers/media/v4l2-core/videodev.ko] undefined!


'of_get_next_parent()' should be exported for use by modules...?


Yes, there was already a patch submitted for this [1]. Hopefully it gets
picked soon so we don't see such errors. That's my oversight, sorry 
about it.


[1] http://www.spinics.net/lists/linux-media/msg61994.html

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 00/30] ARM: exynos multiplatform support

2013-04-10 Thread Arnd Bergmann
Hi everyone,

I have updated my series for multiplatform support of the ARM exynos
platform, based on what is currently queued up in arm-soc.

It would be really nice to still get this merged for 3.10. A lot of
the patches are really trivial, but there are some complex ones
as well.

To all subsystem maintainers: feel free to directly apply the patches
for your subsystem, there should be no dependencies between any of them,
aside from the last patch requiring all of the earlier ones to be applied
first. Getting an Ack is also fine so we can put the patches into arm-soc.

Arnd

Arnd Bergmann (30):
  ARM: exynos: introduce EXYNOS_ATAGS symbol
  ARM: exynos: prepare for sparse IRQ
  ARM: exynos: move debug-macro.S to include/debug/
  ARM: samsung: move mfc device definition to s5p-dev-mfc.c
  tty: serial/samsung: prepare for common clock API
  tty: serial/samsung: make register definitions global
  tty: serial/samsung: fix modular build
  i2c: s3c2410: make header file local
  mmc: sdhci-s3c: remove platform dependencies
  usb: exynos: do not include plat/usb-phy.h
  [media] exynos: remove unnecessary header inclusions
  video/exynos: remove unnecessary header inclusions
  video/s3c: move platform_data out of arch/arm
  thermal/exynos: remove unnecessary header inclusions
  mtd: onenand/samsung: make regs-onenand.h file local
  rtc: s3c: make header file local
  pwm: samsung: repair the worst MMIO abuses
  ASoC: samsung: move plat/ headers to local directory
  ASoC: samsung: use irq resource for idma
  ASoC: samsung: convert to dmaengine API
  ASoC: samsung/i2s: fix module_device_table
  ASoC: samsung/idma: export idma_reg_addr_init
  clk: exynos: prepare for multiplatform
  clocksource: exynos_mct: remove platform header dependency
  irqchip: exynos: pass max combiner number to combiner_init
  irqchip: exynos: allocate combiner_data dynamically
  irqchip: exynos: localize irq lookup for ATAGS
  irqchip: exynos: pass irq_base from platform
  spi: s3c64xx: move to generic dmaengine API
  ARM: exynos: enable multiplatform support

 arch/arm/Kconfig   |  10 +-
 arch/arm/Kconfig.debug |   8 +
 arch/arm/configs/exynos4_defconfig |   2 +-
 .../mach/debug-macro.S = include/debug/exynos.S}  |  12 +-
 .../plat/debug-macro.S = include/debug/samsung.S} |   2 +-
 arch/arm/mach-exynos/Kconfig   |  40 ++-
 arch/arm/mach-exynos/Makefile  |   5 +-
 arch/arm/mach-exynos/common.c  |  26 +-
 arch/arm/mach-exynos/common.h  |   7 +-
 arch/arm/mach-exynos/dev-uart.c|   1 +
 arch/arm/mach-exynos/include/mach/irqs.h   |   5 +-
 arch/arm/mach-exynos/mach-armlex4210.c |   2 +
 arch/arm/mach-exynos/mach-exynos4-dt.c |   3 +
 arch/arm/mach-exynos/mach-exynos5-dt.c |   2 +
 arch/arm/mach-exynos/mach-nuri.c   |   2 +
 arch/arm/mach-exynos/mach-origen.c |   2 +
 arch/arm/mach-exynos/mach-smdk4x12.c   |   2 +
 arch/arm/mach-exynos/mach-smdkv310.c   |   3 +
 arch/arm/mach-exynos/setup-sdhci-gpio.c|   2 +-
 arch/arm/mach-exynos/setup-usb-phy.c   |   8 +-
 arch/arm/mach-s3c24xx/clock-s3c2440.c  |   5 +
 arch/arm/mach-s3c24xx/common.c |   5 +
 arch/arm/mach-s3c24xx/dma-s3c2410.c|   2 -
 arch/arm/mach-s3c24xx/dma-s3c2412.c|   2 -
 arch/arm/mach-s3c24xx/dma-s3c2440.c|   2 -
 arch/arm/mach-s3c24xx/dma-s3c2443.c|   2 -
 arch/arm/mach-s3c24xx/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c|   1 -
 arch/arm/mach-s3c64xx/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s3c64xx/setup-usb-phy.c  |   4 +-
 arch/arm/mach-s5p64x0/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s5pc100/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s5pc100/setup-sdhci-gpio.c   |   1 -
 arch/arm/mach-s5pv210/include/mach/debug-macro.S   |   2 +-
 arch/arm/mach-s5pv210/setup-sdhci-gpio.c   |   1 -
 arch/arm/mach-s5pv210/setup-usb-phy.c  |   4 +-
 arch/arm/plat-samsung/Kconfig  |   7 +-
 arch/arm/plat-samsung/Makefile |   8 +-
 arch/arm/plat-samsung/devs.c   |  62 ++---
 arch/arm/plat-samsung/include/plat/fb.h|  50 +---
 arch/arm/plat-samsung/include/plat/pm.h|   5 +
 arch/arm/plat-samsung/include/plat/regs-serial.h   | 282 +
 arch/arm/plat-samsung/include/plat/sdhci.h |  56 +---
 arch/arm/plat-samsung/include/plat/usb-phy.h   |   5 +-
 arch/arm/plat-samsung/irq-vic-timer.c  |   1 +
 arch/arm/plat-samsung/pm.c |   1 +
 arch/arm/plat-samsung/s5p-dev-mfc.c|  42 ++-
 arch/arm/plat-samsung/s5p-irq.c|   

[PATCH 11/30] [media] exynos: remove unnecessary header inclusions

2013-04-10 Thread Arnd Bergmann
In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.

Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
 drivers/media/platform/s5p-tv/sii9234_drv.c  | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c 
b/drivers/media/platform/exynos-gsc/gsc-regs.c
index 6f5b5a4..e22d147 100644
--- a/drivers/media/platform/exynos-gsc/gsc-regs.c
+++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
@@ -12,7 +12,6 @@
 
 #include linux/io.h
 #include linux/delay.h
-#include mach/map.h
 
 #include gsc-core.h
 
diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c 
b/drivers/media/platform/s5p-tv/sii9234_drv.c
index d90d228..39b77d2 100644
--- a/drivers/media/platform/s5p-tv/sii9234_drv.c
+++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
@@ -23,9 +23,6 @@
 #include linux/regulator/machine.h
 #include linux/slab.h
 
-#include mach/gpio.h
-#include plat/gpio-cfg.h
-
 #include media/sii9234.h
 #include media/v4l2-subdev.h
 
-- 
1.8.1.2

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


Re: [PATCH 11/30] [media] exynos: remove unnecessary header inclusions

2013-04-10 Thread Mauro Carvalho Chehab
Em Thu, 11 Apr 2013 02:04:53 +0200
Arnd Bergmann a...@arndb.de escreveu:

 In multiplatform configurations, we cannot include headers
 provided by only the exynos platform. Fortunately a number
 of drivers that include those headers do not actually need
 them, so we can just remove the inclusions.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: linux-media@vger.kernel.org
 Cc: Mauro Carvalho Chehab mche...@redhat.com

Acked-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/platform/exynos-gsc/gsc-regs.c | 1 -
  drivers/media/platform/s5p-tv/sii9234_drv.c  | 3 ---
  2 files changed, 4 deletions(-)
 
 diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c 
 b/drivers/media/platform/exynos-gsc/gsc-regs.c
 index 6f5b5a4..e22d147 100644
 --- a/drivers/media/platform/exynos-gsc/gsc-regs.c
 +++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
 @@ -12,7 +12,6 @@
  
  #include linux/io.h
  #include linux/delay.h
 -#include mach/map.h
  
  #include gsc-core.h
  
 diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c 
 b/drivers/media/platform/s5p-tv/sii9234_drv.c
 index d90d228..39b77d2 100644
 --- a/drivers/media/platform/s5p-tv/sii9234_drv.c
 +++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
 @@ -23,9 +23,6 @@
  #include linux/regulator/machine.h
  #include linux/slab.h
  
 -#include mach/gpio.h
 -#include plat/gpio-cfg.h
 -
  #include media/sii9234.h
  #include media/v4l2-subdev.h
  


-- 

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


Re: [PATCH v8 1/7] media: V4L2: add temporary clock helpers

2013-04-10 Thread Barry Song
Hi Guennadi,

 Typical video devices like camera sensors require an external clock source.
 Many such devices cannot even access their hardware registers without a
 running clock. These clock sources should be controlled by their consumers.
 This should be performed, using the generic clock framework. Unfortunately
 so far only very few systems have been ported to that framework. This patch
 adds a set of temporary helpers, mimicking the generic clock API, to V4L2.
 Platforms, adopting the clock API, should switch to using it. Eventually
 this temporary API should be removed.

 Signed-off-by: Guennadi Liakhovetski g.liakhovetski@xx
 ---

for your patch 1/8 and 3/8, i think it makes a lot of senses to let
the object manages its own clock by itself.
is it possible for us to implement v4l2-clk.c directly as an instance
of standard clk driver for those systems which don't have generic
clock,  and remove the V4L2 clock APIs like v4l2_clk_get,
v4l2_clk_enable from the first day? i mean v4l2-clk.c becomes a temp
and fake clock controller driver. finally, after people have
generically clk, remove it.

 v8: Updated both (C) dates

  drivers/media/v4l2-core/Makefile   |2 +-
  drivers/media/v4l2-core/v4l2-clk.c |  177 
 
  include/media/v4l2-clk.h   |   54 +++
  3 files changed, 232 insertions(+), 1 deletions(-)
  create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
  create mode 100644 include/media/v4l2-clk.h

 diff --git a/drivers/media/v4l2-core/Makefile 
 b/drivers/media/v4l2-core/Makefile
 index aa50c46..628c630 100644
 --- a/drivers/media/v4l2-core/Makefile
 +++ b/drivers/media/v4l2-core/Makefile
 @@ -5,7 +5,7 @@
  tuner-objs   :=  tuner-core.o

  videodev-objs:=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o 
 \
 - v4l2-event.o v4l2-ctrls.o v4l2-subdev.o
 + v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
 ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
  endif
 diff --git a/drivers/media/v4l2-core/v4l2-clk.c 
 b/drivers/media/v4l2-core/v4l2-clk.c
 new file mode 100644
 index 000..d7cc13e
 --- /dev/null
 +++ b/drivers/media/v4l2-core/v4l2-clk.c
 @@ -0,0 +1,177 @@

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