uvcvideo: Dropping payload (out of sync)
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()
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()
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
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.
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.
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.
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
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
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
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
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
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/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
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/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
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/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.
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.
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
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()
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
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)
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)
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
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
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
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
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