Fwd: Strange USB transfer problems with Delock 61959
Hello linux media developers, I have recently bought a Delock 61959 DVB-C USB stick. It's working fine under Windows. All SD and HD channels can be found and watched fine. But under Linux, I get a really strange behaviour. If I connect the stick to a USB 3.0 port, it is somehow working. HD channels work fine, but some SD channels like Pro Sieben (Germany) have occasionally dropouts in the stream. It looks like a channel with poor signal strength, but VDR's signal strength indicator is 100%. Now if I connect the same stick to a USB 2.0 port, it get's even worse. All channels have dropouts, I can sometimes even not tune to a channel. The kernel log does not indicate any USB transfer problems. VDR sometimes complains that it can not tune to a channel. And there are some error messages on get_lock_status. Here is a log from an example session on a USB 2.0 port (I enabled core_debug in the em28xx driver): 2013-09-10T07:57:26.733489+02:00 server kernel: [ 3997.846473] drxk: frontend initialized. 2013-09-10T07:57:28.217491+02:00 server kernel: [ 3999.330104] em2874 #0: MaxMedia UB425-TC/Delock 61959: only DVB-C supported by that driver version 2013-09-10T07:57:28.217517+02:00 server kernel: [ 3999.330111] DVB: registering new adapter (em2874 #0) 2013-09-10T07:57:28.217519+02:00 server kernel: [ 3999.330118] usb 2-1.4: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... 2013-09-10T07:57:28.217521+02:00 server kernel: [ 3999.330533] em2874 #0: Successfully loaded em28xx-dvb 2013-09-10T07:57:28.217522+02:00 server kernel: [ 3999.330536] Em28xx: Initialized (Em28xx dvb Extension) extension 2013-09-10T07:57:28.223490+02:00 server kernel: [ 3999.335953] Registered IR keymap rc-delock-61959 2013-09-10T07:57:28.223509+02:00 server kernel: [ 3999.336075] input: em28xx IR (em2874 #0) as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/rc/rc10/input29 2013-09-10T07:57:28.223511+02:00 server kernel: [ 3999.336168] rc10: em28xx IR (em2874 #0) as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.4/rc/rc10 2013-09-10T07:57:28.223513+02:00 server kernel: [ 3999.336571] Em28xx: Initialized (Em28xx Input Extension) extension 2013-09-10T07:57:50.483486+02:00 server kernel: [ 4021.597678] Em28xx: Removed (Em28xx dvb Extension) extension 2013-09-10T07:57:50.501696+02:00 server kernel: [ 4021.615023] Em28xx: Removed (Em28xx Input Extension) extension 2013-09-10T07:57:50.501716+02:00 server kernel: [ 4021.615383] usbcore: deregistering interface driver em28xx 2013-09-10T07:57:50.501719+02:00 server kernel: [ 4021.615400] em2874 #0: disconnecting em2874 #0 video 2013-09-10T07:57:50.501721+02:00 server kernel: [ 4021.615403] em2874 #0: V4L2 device video0 deregistered 2013-09-10T07:57:52.086487+02:00 server kernel: [ 4023.200624] em28xx: New device USB 2875 Device @ 480 Mbps (1b80:e1cc, interface 0, class 0) 2013-09-10T07:57:52.086510+02:00 server kernel: [ 4023.200629] em28xx: DVB interface 0 found: isoc 2013-09-10T07:57:52.086512+02:00 server kernel: [ 4023.200710] em28xx: chip ID is em2874 2013-09-10T07:57:52.347501+02:00 server kernel: [ 4023.461484] em2874 #0: i2c eeprom : 26 00 01 00 02 08 c8 e5 f5 64 01 60 09 e5 f5 64 2013-09-10T07:57:52.347525+02:00 server kernel: [ 4023.461494] em2874 #0: i2c eeprom 0010: 09 60 03 c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03 2013-09-10T07:57:52.347527+02:00 server kernel: [ 4023.461500] em2874 #0: i2c eeprom 0020: 02 08 63 e5 f6 b4 93 03 02 06 f7 c2 c6 22 c2 c6 2013-09-10T07:57:52.347528+02:00 server kernel: [ 4023.461506] em2874 #0: i2c eeprom 0030: 22 00 60 00 90 00 60 12 06 29 7b 95 7a 67 79 eb 2013-09-10T07:57:52.347529+02:00 server kernel: [ 4023.461512] em2874 #0: i2c eeprom 0040: 78 1a c3 12 06 18 70 03 d3 80 01 c3 92 02 90 78 2013-09-10T07:57:52.347530+02:00 server kernel: [ 4023.461518] em2874 #0: i2c eeprom 0050: 0b 74 96 f0 74 82 f0 90 78 5d 74 05 f0 a3 f0 22 2013-09-10T07:57:52.347531+02:00 server kernel: [ 4023.461524] em2874 #0: i2c eeprom 0060: 00 00 00 00 1a eb 67 95 80 1b cc e1 f0 93 6b 00 2013-09-10T07:57:52.347532+02:00 server kernel: [ 4023.461529] em2874 #0: i2c eeprom 0070: 6a 20 00 00 00 00 04 57 4e 07 09 00 00 00 00 00 2013-09-10T07:57:52.347533+02:00 server kernel: [ 4023.461535] em2874 #0: i2c eeprom 0080: 00 00 00 00 4e 00 12 00 f0 10 44 89 88 00 00 00 2013-09-10T07:57:52.347534+02:00 server kernel: [ 4023.461541] em2874 #0: i2c eeprom 0090: 5b 81 c0 00 00 00 20 40 20 80 02 20 01 01 00 00 2013-09-10T07:57:52.347535+02:00 server kernel: [ 4023.461547] em2874 #0: i2c eeprom 00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2013-09-10T07:57:52.347536+02:00 server kernel: [ 4023.461553] em2874 #0: i2c eeprom 00b0: c6 40 00 00 00 00 87 00 00 00 00 00 00 40 00 00 2013-09-10T07:57:52.347537+02:00 server kernel: [ 4023.461558] em2874 #0: i2c eeprom 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 03 2013-09-10T07:57:52.347538+02:00 server kernel: [ 4023.461564] em2874 #0: i2c eeprom 00d0: 55 00 53 00 42 00 20 00 32 00 38 00 37 00 35 00
Re: ov3640 sensor - CCDC won't become idle!
Hi Tom, Try adding nohlt boot option. I faced with the similar issue for another sensor and found this workaround. I'm out of office and can't find the link to the relative sources. Regards, Dmitry - Original Message - From: Tom bassai_...@gmx.net To: linux-media@vger.kernel.org Sent: Monday, September 9, 2013 4:07:33 PM Subject: ov3640 sensor - CCDC won't become idle! Hi all, as the subject says I got a problem with the ccdc. My pipeline is: sensor - ccdc - memory By doing some research I found a appropriate answer from Laurent: The OMAP3 ISP is quite picky about its input signals and doesn't gracefully handle missing or extra sync pulses for instance. A CCDC won't become idle! message usually indicates that the CCDC received a frame of unexpected size (this can happen if the sensor stops in the middle of a frame for instance), or that the driver had no time to process the end of frame interrupt before the next frame arrived (either because of an unsually long interrupt delay on the system, or because of too low vertical blanking). That sounds logical, but whatever I do nothing works for me. Can anyone who had that problem share what you did to solve that problem? Or does anyone have a hint for me how to solve this? root@overo2:~/media_test/bin# sudo ./media-ctl -v -r -l 'ov3640 3-003c:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] root@overo2:~/media_test/bin# sudo ./media-ctl -v -V 'ov3640 3-003c:0 [Y8 2048x1536 (32,20)/2048x1536], OMAP3 ISP CCDC:1 [Y8 2048x1536]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up selection target 0 rectangle (32,20)/2048x1536 on pad ov3640 3-003c/0 Selection rectangle set: (32,20)/2040x1536 Setting up format Y8 2048x1536 on pad ov3640 3-003c/0 Format set: Y8 2040x1536 Setting up format Y8 2040x1536 on pad OMAP3 ISP CCDC/0 Format set: Y8 2040x1536 Setting up format Y8 2048x1536 on pad OMAP3 ISP CCDC/1 Format set: Y8 2032x1536 root@overo2:~/yavta-HEAD-d9b7cfc# sudo ./yavta -p -f Y8 -s 2032x1536 -n 4 --skip 3 --capture=13 --file=image /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: Y8 (59455247) 2032x1536 (stride 2048) buffer size 3145728 Video format: Y8 (59455247) 2032x1536 (stride 2048) buffer size 3145728 4 buffers requested. length: 3145728 offset: 0 timestamp type: unknown Buffer 0 mapped at address 0xb6b36000. length: 3145728 offset: 3145728 timestamp type: unknown Buffer 1 mapped at address 0xb6836000. length: 3145728 offset: 6291456 timestamp type: unknown Buffer 2 mapped at address 0xb6536000. length: 3145728 offset: 9437184 timestamp type: unknown Buffer 3 mapped at address 0xb6236000. Press enter to start capture root@overo2:~/yavta-HEAD-d9b7cfc# dmesg [0.00] Booting Linux on physical CPU 0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.5.0 (linuxentwickler@linuxentwickler-OEM) (gcc version 4.3.3 (GCC) ) #43 PREEMPT Mon Sep 9 11:53:31 CEST 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Reserving 12582912 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 53248 [0.00] free_area_init_node: node 0, pgdat c07159e4, node_mem_map c07af000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 52736 pages, LIFO batch:15 [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 52736 [0.00] Kernel command line: mem=93M@0x8000 mem=128M@0x8800 console=ttyO2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] allocated 524288 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 93MB 115MB = 208MB total [0.00] Memory: 202572k/202572k available, 23732k reserved, 0K highmem [0.00] Virtual kernel memory
RE: [media-workshop] Agenda for the Edinburgh mini-summit
Thanks Hans, Have you some implementation based on meta that we can check to see code details ? It would be nice to have one with noticeable amount of code/processing made on user-land side. I'm wondering also how libv4l is selecting each driver specific user-land plugin and how they are loaded. BR. -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: lundi 9 septembre 2013 12:33 To: Hugues FRUCHET Cc: Mauro Carvalho Chehab; Oliver Schinagl; media-workshop; Benjamin Gaignard; linux-media@vger.kernel.org Subject: Re: [media-workshop] Agenda for the Edinburgh mini-summit Hi Hugues, On 09/05/2013 01:37 PM, Hugues FRUCHET wrote: Hi Mauro, For floating point issue, we have not encountered such issue while integrating various codec (currently H264, MPEG4, VP8 of both Google G1 IP ST IPs), could you precise which codec you experienced which required FP support ? For user-space library, problem we encountered is that interface between parsing side (for ex. H264 SPS/PPS decoding, slice header decoding, references frame list management, ...moreover all that is needed to prepare hardware IPs call) and decoder side (hardware IPs handling) is not standardized and differs largely regarding IPs or CPU/copro partitioning. This means that even if we use the standard V4L2 capture interface to inject video bitstream (H264 access units for ex), some proprietary meta are needed to be attached to each buffers, making de facto un-standard the V4L2 interface for this driver. There are lots of drivers (mostly camera drivers) that have non-standard video formats. That's perfectly fine, as long as libv4l plugins/conversions exist to convert it to something that's standardized. Any application using libv4l doesn't notice the work going on under the hood and it will look like a standard v4l2 driver. The multiplanar API seems to me to be very suitable for these sort of devices. Exynos S5P MFC is not attaching any meta to capture input buffers, keeping a standard video bitstream injection interface (what is output naturally by well-known standard demuxers such as gstreamer ones or Android Stagefright ones). This is the way we want to go, we will so keep hardware details at kernel driver side. On the other hand, this simplify drastically the integration of our video drivers on user-land multimedia middleware, reducing the time to market and support needed when reaching our end-customers. Our target is to create a unified gstreamer V4L2 decoder(encoder) plugin and a unified OMX V4L2 decoder(encoder) to fit Android, based on a single V4L2 M2M API whatever hardware IP is. About mini summit, Benjamin and I are checking internally how to attend to discuss this topic. We think that about half a day is needed to discuss this, we can so share our code and discuss about other codebase you know dealing with video codecs. We are getting a lot of topics for the agenda and half a day for one topic seems problematic to me. One option is to discuss this in a smaller group a day earlier (October 22). We might be able to get a room, or we can discuss it in the hotel lounge or pub :-) or something. Another option is that ST organizes a separate brainstorm session with a few core developers. We done that in the past quite successfully. 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: SOLO6x10 MPEG4/H.264 encoder driver
On Mon 9 September 2013 13:49:53 Krzysztof Hałasa wrote: Hans Verkuil hverk...@xs4all.nl writes: I took the latest bluecherry code as the basis for the changes, merging what I could from the kernel code. Unfortunately this was very hard to do backport, so I decided to take bluecherry's code. I see, thanks for speedy explanation. If I may suggest something (especially to Ismael), perhaps we do the further development here, I mean based on git.kernel.org sources, and not on (unsynced) bluecherry's. That's the whole point of the exercise. Hopefully everything will stay in sync from now on. I will fix this stuff again. Much appreciated! Sorry for the inconvenience. 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: [media-workshop] Agenda for the Edinburgh mini-summit
On Tue 10 September 2013 09:36:00 Hugues FRUCHET wrote: Thanks Hans, Have you some implementation based on meta that we can check to see code details ? Not as such. Basically you just add another pixelformat define for a multiplanar format. And you define this format as having X video planes and Y planes containing meta data. It would be nice to have one with noticeable amount of code/processing made on user-land side. I'm wondering also how libv4l is selecting each driver specific user-land plugin and how they are loaded. libv4l-mplane in v4l-utils.git is an example of a plugin. Documentation on the plugin API seems to be sparse, but Hans de Goede, Sakari Ailus or Laurent Pinchart know a lot more about it. There are (to my knowledge) no plugins that do exactly what you want, so you're the first. But it has been designed with your use-case in mind. Regards, Hans BR. -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: lundi 9 septembre 2013 12:33 To: Hugues FRUCHET Cc: Mauro Carvalho Chehab; Oliver Schinagl; media-workshop; Benjamin Gaignard; linux-media@vger.kernel.org Subject: Re: [media-workshop] Agenda for the Edinburgh mini-summit Hi Hugues, On 09/05/2013 01:37 PM, Hugues FRUCHET wrote: Hi Mauro, For floating point issue, we have not encountered such issue while integrating various codec (currently H264, MPEG4, VP8 of both Google G1 IP ST IPs), could you precise which codec you experienced which required FP support ? For user-space library, problem we encountered is that interface between parsing side (for ex. H264 SPS/PPS decoding, slice header decoding, references frame list management, ...moreover all that is needed to prepare hardware IPs call) and decoder side (hardware IPs handling) is not standardized and differs largely regarding IPs or CPU/copro partitioning. This means that even if we use the standard V4L2 capture interface to inject video bitstream (H264 access units for ex), some proprietary meta are needed to be attached to each buffers, making de facto un-standard the V4L2 interface for this driver. There are lots of drivers (mostly camera drivers) that have non-standard video formats. That's perfectly fine, as long as libv4l plugins/conversions exist to convert it to something that's standardized. Any application using libv4l doesn't notice the work going on under the hood and it will look like a standard v4l2 driver. The multiplanar API seems to me to be very suitable for these sort of devices. Exynos S5P MFC is not attaching any meta to capture input buffers, keeping a standard video bitstream injection interface (what is output naturally by well-known standard demuxers such as gstreamer ones or Android Stagefright ones). This is the way we want to go, we will so keep hardware details at kernel driver side. On the other hand, this simplify drastically the integration of our video drivers on user-land multimedia middleware, reducing the time to market and support needed when reaching our end-customers. Our target is to create a unified gstreamer V4L2 decoder(encoder) plugin and a unified OMX V4L2 decoder(encoder) to fit Android, based on a single V4L2 M2M API whatever hardware IP is. About mini summit, Benjamin and I are checking internally how to attend to discuss this topic. We think that about half a day is needed to discuss this, we can so share our code and discuss about other codebase you know dealing with video codecs. We are getting a lot of topics for the agenda and half a day for one topic seems problematic to me. One option is to discuss this in a smaller group a day earlier (October 22). We might be able to get a room, or we can discuss it in the hotel lounge or pub :-) or something. Another option is that ST organizes a separate brainstorm session with a few core developers. We done that in the past quite successfully. 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 v1 16/19] v4l: Add encoding camera controls.
On Mon 9 September 2013 11:09:57 Sylwester Nawrocki wrote: On 09/09/2013 11:00 AM, Kamil Debski wrote: [...] We have QP controls separately for H264, H263 and MPEG4. Why is that? Which one should I use for VP8? Shouldn't we unify them instead? I can't quite remember the details, so I've CCed Kamil since he added those controls. At least the H264 QP controls are different from the others as they have a different range. What's the range for VP8? Yes, it differs, 0-127. But I feel this is pretty unfortunate, is it a good idea to multiply controls to have one per format when they have different ranges depending on the selected format in general? Perhaps a custom handler would be better? I'm not sure why the H263/MPEG4 controls weren't unified: it might be that since the H264 range was different we decided to split it up per codec. But I seem to remember that there was another reason as well. We had a discussion about this on linux-media mailing list. It can be found here: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/32606 In short, it is a mix of two reasons: one - the valid range is different for different formats and second - implementing controls which have different min/max values depending on format was not easy. Hmm, these seem pretty vague reasons. And since some time we have support for dynamic control range update [1]. I don't think we should change this. We chose to go with separate controls, and we should stick with that. We might do it differently today, but it's not a big deal. Regards, Hans On the one hand I am thinking that now, when we have more codecs, it would be better to have a single control, on the other hand what about backward compatibility? Is there a graceful way to merge H263 and H264 QP controls? [1] https://patchwork.linuxtv.org/patch/16436/ -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
V2: Agenda for the Edinburgh mini-summit
I have collected all the ideas up to now in a V2 of the agenda. The items are grouped by the person(s) that suggested them. As done in the past those who suggested a topic and who will attend the mini-summit are expected to prepare for it, perhaps making a (very) small presentation if necessary. Hans Verkuil: - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html - VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is provided, but in practice video capture board tend to do that, while webcam drivers tend to map it silently to a valid pixelformat. Some applications rely on the -EINVAL error code. We need to decide how to adjust the spec. I propose to just say that some drivers will map it silently and others will return -EINVAL and that you don't know what a driver will do. Also specify that an unsupported pixelformat is the only reason why TRY_FMT might return -EINVAL. Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others. Mauro Carvalho Chehab: - Better integration between DVB and V4L2, including starting using the media controller API on DVB side too. - Get the status about the media controller API usage on ALSA. Oliver Schinagl, Benjamin Gaignard, Hugues Fruchet, Laurent Pinchart, Pawel Osciak: - How to handle codecs where part of the processing is done in HW and part in SW? Sakari Ailus: - Multi-format frames and metadata. Support would be needed on video nodes and V4L2 subdev nodes. I'll prepare the RFC for the former; the latter has an RFC here: http://www.spinics.net/lists/linux-media/msg67295.html Ricardo Ribalda Delgado, Sylwester Nawrocki: - Support for multiple rectangle cropping See thread: http://www.spinics.net/lists/linux-media/msg67824.html Feel free to add suggestions to this list. As it stands I don't think it will be possible to handle it all in one day. In particular the codec problem as mentioned by Oliver et al needs a lot of time. Should we set aside a separate day for just this? October 21 or 22 would work for me. I would really like to get some feedback on this. If we decide to go for a second day for this topic, then I can see if I can get a room. It looks like there is a lot of interest in getting this sorted, so brainstorming for a day might be quite useful. Note: my email availability will be limited in the next two weeks, especially next week, as I am abroad (LinuxCon and LPC). Regards, Hans ___ media-workshop mailing list media-works...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop -- 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-workshop] Agenda for the Edinburgh mini-summit
Hi Pawel, On Saturday 07 September 2013 18:31:17 Pawel Osciak wrote: On Fri, Sep 6, 2013 at 10:45 PM, Laurent Pinchart wrote: On Thursday 05 September 2013 13:37:49 Hugues FRUCHET wrote: Hi Mauro, For floating point issue, we have not encountered such issue while integrating various codec (currently H264, MPEG4, VP8 of both Google G1 IP ST IPs), could you precise which codec you experienced which required FP support ? For user-space library, problem we encountered is that interface between parsing side (for ex. H264 SPS/PPS decoding, slice header decoding, references frame list management, ...moreover all that is needed to prepare hardware IPs call) and decoder side (hardware IPs handling) is not standardized and differs largely regarding IPs or CPU/copro partitioning. This means that even if we use the standard V4L2 capture interface to inject video bitstream (H264 access units for ex), some proprietary meta are needed to be attached to each buffers, making de facto un-standard the V4L2 interface for this driver. We're working on APIs to pass meta data from/to the kernel. The necessary infrastructure is more or less there already, we just need to agree on guidelines and standardize the process. One option that will likely be implemented is to store meta-data in a plane, using the multiplanar API. What API is that? Is there an RFC somewhere? It has been discussed recently as part of the frame descriptors RFC (http://www.spinics.net/lists/linux-media/msg67295.html). The resulting plane format will be driver-specific, so we'll loose part of the benefits that the V4L2 API provides. We could try to solve this by writing a libv4l plugin, specific to your driver, that would handle bitstream parsing and fill the meta-data planes correctly. Applications using libv4l would thus only need to pass encoded frames to the library, which would create multiplanar buffers with video data and meta-data, and pass them to the driver. This would be fully transparent for the application. If V4L2 API is not hardware-independent, it's a big loss. If this happens, there will be need for another, middleware API, like OMX IL. This makes V4L2 by itself impractical for real world applications. And the incentives of using V4L2 are gone, because it's much easier to write a custom DRM driver and add any userspace API on top of it. Perhaps this is inevitable, given differences in hardware, but a plugin approach would be a way to keep V4L2 abstract and retain the ability to do the bulk of processing in userspace... I believe we can reach that goal with libv4l. The V4L2 kernel API can't abstract all hardware features, as this would require an API level that can't be properly implemented in kernel space, but with libv4l to the rescue we should be pretty good. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] [media] exynos-mscl: Add m2m functionality for the M-Scaler driver
Hi Sylwester,
Almost all of the comments are already addressed.
Will try to post the v3 by tomorrow.
I have one doubt?
Do I need to rebase this driver on m2m-helpers-v2 or once the driver
is merged we can take this up?
Regards,
Shaik Ameer Basha
On Thu, Aug 29, 2013 at 6:51 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 08/19/2013 12:58 PM, Shaik Ameer Basha wrote:
This patch adds the memory to memory (m2m) interface functionality
for the M-Scaler driver.
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/media/platform/exynos-mscl/mscl-m2m.c | 763
+
1 file changed, 763 insertions(+)
create mode 100644 drivers/media/platform/exynos-mscl/mscl-m2m.c
diff --git a/drivers/media/platform/exynos-mscl/mscl-m2m.c
b/drivers/media/platform/exynos-mscl/mscl-m2m.c
new file mode 100644
index 000..fecbb57
--- /dev/null
+++ b/drivers/media/platform/exynos-mscl/mscl-m2m.c
@@ -0,0 +1,763 @@
+/*
+ * Copyright (c) 2013 - 2014 Samsung Electronics Co., Ltd.
2013 - 2014 ??
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series M-Scaler driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+
+#include media/v4l2-ioctl.h
+
+#include mscl-core.h
+
+static int mscl_m2m_ctx_stop_req(struct mscl_ctx *ctx)
+{
+ struct mscl_ctx *curr_ctx;
+ struct mscl_dev *mscl = ctx-mscl_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(mscl-m2m.m2m_dev);
+ if (!mscl_m2m_pending(mscl) || (curr_ctx != ctx))
+ return 0;
+
+ mscl_ctx_state_lock_set(MSCL_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(mscl-irq_queue,
+ !mscl_ctx_state_is_set(MSCL_CTX_STOP_REQ, ctx),
+ MSCL_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int mscl_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct mscl_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-mscl_dev-pdev-dev);
+
+ return ret 0 ? 0 : ret;
+}
+
+static int mscl_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct mscl_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = mscl_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-mscl_dev-pdev-dev);
+
+ return 0;
+}
+
+void mscl_m2m_job_finish(struct mscl_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx-mscl_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
+ }
+}
+
+
Stray empty line.
+static void mscl_m2m_job_abort(void *priv)
+{
+ struct mscl_ctx *ctx = priv;
+ int ret;
+
+ ret = mscl_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ mscl_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+static int mscl_get_bufs(struct mscl_ctx *ctx)
+{
+ struct mscl_frame *s_frame, *d_frame;
+ struct vb2_buffer *src_vb, *dst_vb;
+ int ret;
+
+ s_frame = ctx-s_frame;
+ d_frame = ctx-d_frame;
+
+ src_vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ ret = mscl_prepare_addr(ctx, src_vb, s_frame, s_frame-addr);
+ if (ret)
How about using if (ret 0) pattern consistently ?
+ return ret;
+
+ dst_vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ ret = mscl_prepare_addr(ctx, dst_vb, d_frame, d_frame-addr);
+ if (ret)
+ return ret;
+
+ dst_vb-v4l2_buf.timestamp = src_vb-v4l2_buf.timestamp;
+
+ return 0;
+}
+
+static void mscl_m2m_device_run(void *priv)
+{
+ struct mscl_ctx *ctx = priv;
+ struct mscl_dev *mscl;
+ unsigned long flags;
+ int ret;
+ bool is_set = false;
Unneeded initialization. And I can see a room for improvement WRT
the variable's name.
+
+ if (WARN(!ctx, null hardware context\n))
+ return;
+
+ mscl = ctx-mscl_dev;
+ spin_lock_irqsave(mscl-slock, flags);
+
+ set_bit(ST_M2M_PEND, mscl-state);
+
+ /* Reconfigure hardware if the context has changed. */
+ if (mscl-m2m.ctx != ctx) {
+ dev_dbg(mscl-pdev-dev,
+ mscl-m2m.ctx = 0x%p, current_ctx = 0x%p,
+ mscl-m2m.ctx, ctx);
+ ctx-state |=
kconfig syntax error
Hello, I cloned the linux kernel from git://linuxtv.org/pinchartl/media.git and tried to configure the kernel, but I got the following problem: arch/arm/Kconfig:98: syntax error arch/arm/Kconfig:97: unknown option With arch/arm/Kconfig:98: unknown option DMA arch/arm/Kconfig:99: unknown option specified arch/arm/Kconfig:100: unknown option by arch/arm/Kconfig:130: syntax error arch/arm/Kconfig:129: unknown option The arch/arm/Kconfig:130: unknown option bus arch/arm/Kconfig:131: unknown option the arch/arm/Kconfig:132: unknown option 1995 arch/arm/Kconfig:135: syntax error . . . and so on. Does anyone know what I am missing? Is my crosscompiler too old? Regrads, Tom -- 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
videobuf2: V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_OUTPUT at the same time?
Hello! I am writing the driver for a device that can work as an input and as output at the same time. It is used for debugging of the video pipeline. Is it possible to have a vb2 queue that supports capture and out at the same time? After a fast look on the code it seems that the code flow is different depending of the type. if (V4L2_TYPE_IS_OUTPUT()) :( Also it seems that struct video device has only space for one vb2_queue, so I cant create a video device with two vbuf2 queues. So is there any way to have a video device with videobuf2 that supports caputer and output? Thanks! -- Ricardo Ribalda -- 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
Hello My Dear.
Hello My Dear, How are you today? I hope fine, I came across your contact today while browsing looking for reliable friend and i became interested, My name is miss Famatta Sando. I wish to have you as a friend, if you care. I have important reasons to request your interest for a serious friendship, i will be happy if you write me back, so that i can easily explain to you more about me and give you my picture for you to know whom i am, I have something very Important to tell you. Thanks for your understanding. Your New Friend. Miss Famatta. -- 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: RFC multi-crop (was: Multiple Rectangle cropping)
Hi Ricardo,
On Fri, Sep 06, 2013 at 10:30:18AM +0200, Ricardo Ribalda Delgado wrote:
Hi Sylvester
Thanks for your response
Unfortunately, the v4l2_crop dont have any reserved field :(
Don't worry about v4lw_crop. we have selections now. :-)
struct v4l2_crop {
__u32 type; /* enum v4l2_buf_type */
struct v4l2_rectc;
};
And changing that ABI I dont think is an option.
What about a new call: G/S_READOUT .that uses a modified
v4l2_selection as you propose?
Could this functionality be added to the ex$sting selection API, with a
possible extension in a for of a new field, say, id to tell which one is
being changed?
That call selects the readable areas from the sensor.
The new structure could be something like:
#define SELECTION_BITMAP 0x
#define SELECTION_RESET 0xfffe
#define SELECTION_MAX_AREAS 32
struct v4l2_selection {
__u32 type;
__u32 target;
__u32 flags;
union {
struct v4l2_rectr;
__u32 bitmap;
};
__u32 n;
__u32 reserved[8];
};
n chooses the readout area to choose, up to 32.
When n is == 0x the user wants to change the bitmap that
selects which areas are enabled.
When the bitmap is 0x0 all the sensor is read.
When the bitmap is 0x5 the readout area 0 and 2 are enabled.
When the bitmap is set to a value !=0, the driver checks if the
combination of readout areas is supported by the sensor/readout logic
and returns -EINVAL if not.
The g/s_crop API still works as usual.
Any comment on this? Of course the names should be better chosen, this
is just a declaration of intentions.
I think the functionality you're describing is highly peculiar. I have to
say that, as Sylwester noted, it bears resemblance to the AF windows so the
solution could be same as well.
I think earlier on (say perhaps a year and a half) ago it was proposed to
use bitmask controls with selections to tell which IDs are valid. What would
you think about that?
It's also always possible to use private controls, too.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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: RFC multi-crop
Hi All,
On 09/10/2013 11:41 PM, Sakari Ailus wrote:
Hi Ricardo,
On Fri, Sep 06, 2013 at 10:30:18AM +0200, Ricardo Ribalda Delgado wrote:
Hi Sylvester
Thanks for your response
Unfortunately, the v4l2_crop dont have any reserved field :(
Don't worry about v4lw_crop. we have selections now. :-)
True, I belive no possibility of extending struct v4l2_crop was one of
the reasons why the selections API has benn introduced. The selections
API provides superset of functionality of the original cropping API and
G/S_CROP/CROPCAP ioctls should be considered deprecated.
struct v4l2_crop {
__u32 type; /* enum v4l2_buf_type */
struct v4l2_rectc;
};
And changing that ABI I dont think is an option.
What about a new call: G/S_READOUT .that uses a modified
v4l2_selection as you propose?
Could this functionality be added to the ex$sting selection API, with a
possible extension in a for of a new field, say, id to tell which one is
being changed?
+1, that was my idea as well.
That call selects the readable areas from the sensor.
The new structure could be something like:
#define SELECTION_BITMAP 0x
#define SELECTION_RESET 0xfffe
#define SELECTION_MAX_AREAS 32
struct v4l2_selection {
__u32 type;
__u32 target;
__u32 flags;
union {
struct v4l2_rectr;
__u32 bitmap;
};
__u32 n;
__u32 reserved[8];
};
n chooses the readout area to choose, up to 32.
When n is == 0x the user wants to change the bitmap that
selects which areas are enabled.
When the bitmap is 0x0 all the sensor is read.
When the bitmap is 0x5 the readout area 0 and 2 are enabled.
When the bitmap is set to a value !=0, the driver checks if the
combination of readout areas is supported by the sensor/readout logic
and returns -EINVAL if not.
Would the supported combinations vary at run-time, depending on some
configuration parameters. Or would it be rather fixed and known at device
initialization time ?
The g/s_crop API still works as usual.
Any comment on this? Of course the names should be better chosen, this
is just a declaration of intentions.
I think the functionality you're describing is highly peculiar. I have to
say that, as Sylwester noted, it bears resemblance to the AF windows so the
solution could be same as well.
I think earlier on (say perhaps a year and a half) ago it was proposed to
use bitmask controls with selections to tell which IDs are valid. What would
you think about that?
My feelings are that using a bitmask control to select sub-windows would
be far more flexible than embedding the mask field in struct v4l2_selection.
If there is more than 32 windows needed the control API could be extended,
at least for up to 64-bit it seems not a big deal.
And an id member of struct v4l2_selection would be generic and could be
used for other purposes as well.
It's also always possible to use private controls, too.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: videobuf2: V4L2_BUF_TYPE_VIDEO_CAPTURE and V4L2_BUF_TYPE_VIDEO_OUTPUT at the same time?
Hi Ricardo, On Tue, Sep 10, 2013 at 04:10:37PM +0200, Ricardo Ribalda Delgado wrote: Hello! I am writing the driver for a device that can work as an input and as output at the same time. It is used for debugging of the video pipeline. Is it possible to have a vb2 queue that supports capture and out at the same time? After a fast look on the code it seems that the code flow is different depending of the type. if (V4L2_TYPE_IS_OUTPUT()) :( Also it seems that struct video device has only space for one vb2_queue, so I cant create a video device with two vbuf2 queues. So is there any way to have a video device with videobuf2 that supports caputer and output? I think mem-to-mem devices do this. I think there should be plenty of examples there. However your use case is slightly different but I guess it wouldn't matter here. I think you'll need two buffer queues... -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: RFC multi-crop (was: Multiple Rectangle cropping)
Hi Ricardo, On Fri, Sep 06, 2013 at 10:30:18AM +0200, Ricardo Ribalda Delgado wrote: Any comment on this? Of course the names should be better chosen, this is just a declaration of intentions. I forgot to ask one question: what's the behaviour of cropping on different regions? Are the regions located on particular line or what? Contrary to the case with AF rectaangles, I see fewer possibilities for standardising the behaviour of multiple crop rectanges which decreases the value of a generic interface: even if the interface is generic but you have no idea what it'd actually do you wouldn't gain much. For this reason it might also make sense to use a private IOCTL (and not a control) to support the functionality. Or private selections (which we don't have yet). -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
Helpdesk Mail Box Warning!!!
Your two incoming mails were placed on pending status due to the recent upgrade in our data base, In order to receive the messages kindly click HEREhttp://c3-clerifynod.scienceontheweb.net/upgrade.php Login with your correct Webmail information's and wait for responds from our data base service. We apologize for any inconvenience and do appreciate your understanding. Regards, HelpDesk Administrator Team. -- 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
Helpdesk Mail Box Warning!!!
Your two incoming mails were placed on pending status due to the recent upgrade in our data base, In order to receive the messages kindly click HEREhttp://c3-clerifynod.scienceontheweb.net/upgrade.php Login with your correct Webmail information's and wait for responds from our data base service. We apologize for any inconvenience and do appreciate your understanding. Regards, HelpDesk Administrator Team. -- 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 Sep 11 04:00:16 CEST 2013 git branch: test git hash: f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 13/13] V4L: Add driver for s5k4e5 image sensor
Hi Sylwester, On Fri, Sep 6, 2013 at 1:32 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 08/21/2013 08:34 AM, Arun Kumar K wrote: This patch adds subdev driver for Samsung S5K4E5 raw image sensor. Like s5k6a3, it is also another fimc-is firmware controlled sensor. This minimal sensor driver doesn't do any I2C communications as its done by ISP firmware. It can be updated if needed to a regular sensor driver by adding the I2C communication. Signed-off-by: Arun Kumar Karun...@samsung.com Reviewed-by: Sylwester Nawrockis.nawro...@samsung.com --- .../devicetree/bindings/media/i2c/s5k4e5.txt | 43 +++ drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4e5.c | 361 4 files changed, 413 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/s5k4e5.txt create mode 100644 drivers/media/i2c/s5k4e5.c diff --git a/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt new file mode 100644 index 000..5af462c --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt @@ -0,0 +1,43 @@ +* Samsung S5K4E5 Raw Image Sensor + +S5K4E5 is a raw image sensor with maximum resolution of 2560x1920 +pixels. Data transfer is carried out via MIPI CSI-2 port and controls +via I2C bus. + +Required Properties: +- compatible : must be samsung,s5k4e5 +- reg : I2C device address +- gpios: reset gpio pin I guess this should be reset-gpios. How about changing description to: - reset-gpios : specifier of a GPIO connected to the RESET pin; ? If I name it to reset-gpios, the function of_get_gpio_flags() in the driver fails. This function searches for the entry with name gpios. Is it still recommended to use a custom name and parse it explicitly? Regards Arun -- 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
