Re: [patch] [media] gspca: passing wrong length parameter to reg_w()
On Wed, 2 May 2012 09:15:25 +0300
Dan Carpenter dan.carpen...@oracle.com wrote:
This looks like a cut an paste error. This is a two byte array but we
use 8 as a length parameter.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is a static checker fix. I don't own the hardware.
diff --git a/drivers/media/video/gspca/conex.c
b/drivers/media/video/gspca/conex.c
index ea17b5d..f39fee0 100644
--- a/drivers/media/video/gspca/conex.c
+++ b/drivers/media/video/gspca/conex.c
@@ -306,7 +306,7 @@ static void cx_sensor(struct gspca_dev*gspca_dev)
reg_w(gspca_dev, 0x0020, reg20, 8);
reg_w(gspca_dev, 0x0028, reg28, 8);
- reg_w(gspca_dev, 0x0010, reg10, 8);
+ reg_w(gspca_dev, 0x0010, reg10, 2);
reg_w_val(gspca_dev, 0x0092, 0x03);
switch (gspca_dev-cam.cam_mode[(int) gspca_dev-curr_mode].priv) {
@@ -326,7 +326,7 @@ static void cx_sensor(struct gspca_dev*gspca_dev)
}
reg_w(gspca_dev, 0x007b, reg7b, 6);
reg_w_val(gspca_dev, 0x00f8, 0x00);
- reg_w(gspca_dev, 0x0010, reg10, 8);
+ reg_w(gspca_dev, 0x0010, reg10, 2);
reg_w_val(gspca_dev, 0x0098, 0x41);
for (i = 0; i 11; i++) {
if (i == 3 || i == 5 || i == 8)
Hi Dan,
Thanks for the patch. The bug is very very old (6 years, at least -
neither have I such a webcam).
Maybe the fix could have been
reg_w(gspca_dev, 0x0010, reg10, sizeof reg10);
but it is OK for me.
Acked-by: Jean-Francois Moine http://moinejf.free.fr
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] [media] gspca: passing wrong length parameter to reg_w()
On Wed, May 02, 2012 at 08:47:58AM +0200, Jean-Francois Moine wrote: Thanks for the patch. The bug is very very old (6 years, at least - neither have I such a webcam). My guess is that it's harmless to write a few extra garbage bits, but it's still worth fixing as a cleanup. Maybe the fix could have been reg_w(gspca_dev, 0x0010, reg10, sizeof reg10); but it is OK for me. Acked-by: Jean-Francois Moine http://moinejf.free.fr Thanks. regards, dan carpenter -- 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
[GIT PATCHES FOR 3.4] gspca for_v3.4
The following changes since commit 976a87b9ce3172065e21f0d136353a01df06d0d6: [media] gspca - sn9c20x: Change the exposure setting of Omnivision sensors (2012-04-09 14:22:52 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.4 for you to fetch changes up to 3f46715c09b017bfdfa8c0f5ea284d42a9c213a2: gspca - sonixj: Fix a zero divide in isoc interrupt (2012-05-02 09:05:18 +0200) Jean-François Moine (1): gspca - sonixj: Fix a zero divide in isoc interrupt drivers/media/video/gspca/sonixj.c |8 1 file changed, 4 insertions(+), 4 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Please can someone shed a little light on this? Greatly appreciated, Karl On Tue 120424, Karl Kiniger wrote: Dear all, guvcview does not display the extra controls (focus, led etc) any more since kernel 3.2 an higher (Fedora 16, x86_64). after the various video modes it says: vid:046d pid:0990 driver:uvcvideo Adding control for Pan (relative) UVCIOC_CTRL_ADD - Error: Inappropriate ioctl for device checking format: 1196444237 VIDIOC_G_COMP:: Inappropriate ioctl for device fps is set to 1/25 drawing controls Checking video mode 640x480@32bpp : OK -- /usr/bin/uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous range of choice IDs found [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0901, name = 'Exposure, Auto' Importing dynamic controls from file /usr/share/uvcdynctrl/data/046d/logitech.xml. ERROR: Unable to import dynamic controls: Invalid device or device cannot be opened. (Code: 5) /usr/share/uvcdynctrl/data/046d/logitech.xml: error: device 'video0' \ skipped because the driver 'uvcvideo' behind it does not seem to support \ dynamic controls. -- Is there work in progess to get the missing functionality back? Can I help somehow? Greetings, Karl -- 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: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Karl Hi, I'm using a 3.2 kernel and I haven't notice this problem, can you check the exact version that causes it. Regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: Please can someone shed a little light on this? Greatly appreciated, Karl On Tue 120424, Karl Kiniger wrote: Dear all, guvcview does not display the extra controls (focus, led etc) any more since kernel 3.2 an higher (Fedora 16, x86_64). after the various video modes it says: vid:046d pid:0990 driver:uvcvideo Adding control for Pan (relative) UVCIOC_CTRL_ADD - Error: Inappropriate ioctl for device checking format: 1196444237 VIDIOC_G_COMP:: Inappropriate ioctl for device fps is set to 1/25 drawing controls Checking video mode 640x480@32bpp : OK -- /usr/bin/uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml [libwebcam] Unsupported V4L2_CID_EXPOSURE_AUTO control with a non-contiguous range of choice IDs found [libwebcam] Invalid or unsupported V4L2 control encountered: ctrl_id = 0x009A0901, name = 'Exposure, Auto' Importing dynamic controls from file /usr/share/uvcdynctrl/data/046d/logitech.xml. ERROR: Unable to import dynamic controls: Invalid device or device cannot be opened. (Code: 5) /usr/share/uvcdynctrl/data/046d/logitech.xml: error: device 'video0' \ skipped because the driver 'uvcvideo' behind it does not seem to support \ dynamic controls. -- Is there work in progess to get the missing functionality back? Can I help somehow? Greetings, Karl -- 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
[GIT PULL for v3.5] (v2) uvcvideo fixes
Hi Mauro, Here's one more uvcvideo patch for v3.5. The first two patches have already been submitted in a previous pull request. The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Laurent Pinchart (3): uvcvideo: Fix ENUMINPUT handling MAINTAINERS: Update UVC driver's mailing list address uvcvideo: Use videobuf2 .get_unmapped_area() implementation MAINTAINERS |2 +- drivers/media/video/uvc/uvc_queue.c | 43 ++ drivers/media/video/uvc/uvc_v4l2.c |2 +- 3 files changed, 15 insertions(+), 32 deletions(-) -- 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: omap3isp: isp_video_mbus_to_pix causes WARN_ON
Hi Chris, On Thursday 26 April 2012 10:54:58 Chris Whittenburg wrote: I'm using a 3.0.17 kernel on a dm3730 with a custom 8-bit grayscale sensor. When using a simple gstreamer pipeline to test: gst-launch -v v4l2src device=/dev/video2 ! 'video/x-raw-gray,bpp=(int)8,framerate=(fraction)10/1,width=640,height=480' ! fakesink I get lots of calls to isp_video_try_format for unrelated formats like YU12, YV12, BGR3, and RGB3. I assume this is gstreamer's fault, since I implemented isp_video_enum_format which only returns V4L2_PIX_FMT_GREY. Anyway, isp_video_try_format makes calls to isp_video_pix_to_mbus for each of these formats, and since they aren't in the list of isp_format_info formats, WARN_ON gets called. Is this expected? What would be the best way to resolve it? This has been fixed in commit c3cd257402fdcd650816ec25b83480a24912430a Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Mon Nov 28 08:25:30 2011 -0300 [media] omap3isp: video: Don't WARN() on unknown pixel formats When mapping from a V4L2 pixel format to a media bus format in the VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may be unsupported by the driver. Return a hardcoded format instead of WARN()ing in that case. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com -- 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: RFC: Improve VIDIOC_S_HW_FREQ_SEEK
On Tuesday 01 May 2012 18:19:39 halli manjunatha wrote: On Tue, May 1, 2012 at 4:46 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all! While working on a test function for the hardware seek functionality in v4l2-compliance I realized that the specification is rather vague and incomplete, making it hard to write a decent test for it. There are a number of issues with this API: 1) There is no way for the application to know whether the hardware supports wrap around scanning or not (or both). It is only reported because the ioctl will return EINVAL if it doesn't support it, which is rather awkward. It's important for applications to know what to do here. The solution would be to add two new capability flags to struct v4l2_tuner: V4L2_TUNER_CAP_SEEK_BOUNDED and V4L2_TUNER_CAP_SEEK_WRAP. 2) What happens when the seek didn't find anything? It's not a timeout, it has to return some decent error code. I propose ENODATA for this. 3) What should the frequency be if the seek returns an error? I think the original frequency should be restored in that case. Isn't this the way how it is now? means driver won't change the G_FREQUENCY value till it gets the new valid station during seek. That's how it is done today, but that behavior is not specified in the v4l2 spec. 4) What should happen if you try to set the frequency while a seek is in operation? In that case -EBUSY should be returned by VIDIOC_S_FREQUENCY. 5) What should happen if you try to get the frequency while a seek is in operation? It would be nice if you could get the frequency that is currently being scanned. There are two options to implement this: a) Add a new 'scan_frequency' field to struct v4l2_frequency. So the frequency field would always contain the frequency that was set when the seek started, and the scan_frequency is either 0 (no seek is in progress), a special value V4L2_SCAN_IN_PROGRESS (seek is in progress, but the hardware can't tell what the current seek frequency is) or it contains the frequency that is currently being scanned. b) Add a new V4L2_TUNER_CAP_HAS_SEEK_FREQ capability to struct v4l2_tuner. If set, then VIDIOC_G_FREQUENCY will return the scan frequency when scanning, otherwise it will return the normal frequency. I think I like option a) better. It gives you all the information you need. Even I prefer option A here. 6) What does it mean when you get a time out? The spec just says 'Try again'. But try what? If it times out due to hardware issues, then a proper error should be returned. That leaves a time out due to the scan not finding any channels, but not reaching the end of the scan either (because that would be a ENODATA return code). What should be the frequency in this case? The original frequency or the last scanned frequency? And on older hardware you may not be able to get that last scanned frequency. I suggest one of two options: a) Abolish the time out altogether. The driver author has to set the internal timeout to such a large value that if you time out, then you can just return -ENODATA. b) Hardware that cannot detect the current scan frequency behaves as a). Hardware that can detect the scan frequency will return -EAGAIN, but sets the frequency at the last scanned frequency. Do you have any opinion/insights into this? Regards, Hans 7) It would be nice if the ioctl was RW instead of just a write ioctl. That way the driver could report the proper spacing value that it used. I'm not entirely sure it is worth the effort at this moment though. Comments? Questions? 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 -- 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
Re: [PATCH 07/10] dvb-demux: add functionality to send raw payload to the dvr device
Hi Mike, On Tuesday 01 May 2012 06:12:22 Michael Krufky wrote: From: Michael Krufky mkru...@kernellabs.com If your driver needs to deliver the raw payload to userspace without passing through the kernel demux, use function: dvb_dmx_swfilter_raw I like this one very much. I had a background task sleeping in my head which was how to add non-Transport-Stream standards to Linux-dvb. This one I can now cancel, thanks to this change. We now can add CMMB-support and DAB to linux-dvb (after more discussions on the API of course). Do you have user-space-tool ready which uses the new RAW-payload mechanism? Something which can be used as an example. Thanks for this development. -- Patrick Kernel Labs Inc. http://www.kernellabs.com/ -- 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: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Hi Paulo, I am running plain Fedora 16 on x86_64. The last kernel where UVC dyncontrols worked was 3.1.10-2. (If I remember correctly...) The first kernel with failing dyncontrols was 3.2.1-1 and all later kernels up to 3.3.2-6 fail as well. libwebcam version is libwebcam-0.2.0-4.20100322svn and guvcview is guvcview-1.5.1-1. http://www.quickcamteam.net/software/libwebcam seems to be offline/ discontinued since a few months. what software versions are you running? Is there a later libwebcam available from somewhere else? pls look also at: http://permalink.gmane.org/gmane.linux.kernel/1257500 Greetings, Karl On Wed 120502, Paulo Assis wrote: Karl Hi, I'm using a 3.2 kernel and I haven't notice this problem, can you check the exact version that causes it. Regards, Paulo -- 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
[GIT PULL for v3.5] OMAP3 ISP patches
Hi Mauro, The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-omap3isp-next Laurent Pinchart (17): omap3isp: Prevent pipelines that contain a crashed entity from starting omap3isp: Fix frame number propagation omap3isp: preview: Skip brightness and contrast in configuration ioctl omap3isp: preview: Optimize parameters setup for the common case omap3isp: preview: Remove averager parameter update flag omap3isp: preview: Remove unused isptables_update structure definition omap3isp: preview: Merge configuration and feature bits omap3isp: preview: Remove update_attrs feature_bit field omap3isp: preview: Rename prev_params fields to match userspace API omap3isp: preview: Simplify configuration parameters access omap3isp: preview: Shorten shadow update delay omap3isp: preview: Rename last occurences of *_rgb_to_ycbcr to *_csc omap3isp: preview: Add support for greyscale input omap3isp: Mark probe and cleanup functions with __devinit and __devexit omap3isp: ccdc: Add selection support on output formatter source pad omap3isp: preview: Replace the crop API by the selection API omap3isp: resizer: Replace the crop API by the selection API Sakari Ailus (2): omap3isp: Prevent crash at module unload omap3isp: Handle omap3isp_csi2_reset() errors drivers/media/video/omap3isp/isp.c| 45 ++- drivers/media/video/omap3isp/isp.h|3 +- drivers/media/video/omap3isp/ispccdc.c| 183 - drivers/media/video/omap3isp/ispccdc.h|2 + drivers/media/video/omap3isp/ispccp2.c| 23 - drivers/media/video/omap3isp/ispcsi2.c| 20 +- drivers/media/video/omap3isp/ispcsi2.h|1 - drivers/media/video/omap3isp/ispcsiphy.c |4 +- drivers/media/video/omap3isp/isppreview.c | 633 ++--- drivers/media/video/omap3isp/isppreview.h | 76 +--- drivers/media/video/omap3isp/ispresizer.c | 138 --- drivers/media/video/omap3isp/ispvideo.c |4 + drivers/media/video/omap3isp/ispvideo.h |2 + 13 files changed, 709 insertions(+), 425 deletions(-) -- 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: Using UVC webcam gadget with a real v4l2 device
Hi Bhupesh, On Monday 30 April 2012 18:47:24 Bhupesh SHARMA wrote: On Monday, April 30, 2012 3:51 PM Laurent Pinchart wrote: On Thursday 26 April 2012 13:23:59 Bhupesh SHARMA wrote: Hi Laurent, Sorry to jump-in before your reply on my previous mail, but as I was studying the USERPTR stuff in more detail, I have a few more queries which I believe you can include in your reply as well.. [snip] I am now a bit confused on how the entire system will work now: - Does USERPTR method needs to be supported both in UVC gadget and soc-camera side, or one can still support the MMAP method and the other can now be changed to support USERPTR method and we can achieve a ZERO buffer copy operation using this method? You need USERPTR support on one side only. In practice many (all?) soc- camera drivers require physically contiguous memory, so you will need to use MMAP on the soc-camera side and USERPTR on the UVC gadget side. DMABUF, when merged in the kernel, will be a better solution (but will require all drivers to use vb2). Perfect. So, I plan now to add vb2 support for uvc-gadget and leave soc- camera side to use the mmap stuff. Now, waiting for your pointers for managing the race-conditions in the UVC gadget and also avoiding the memcpy that is happening in the QBUF call on the UVC gadget, before I start the actual work. The memcpy doesn't happen at QBUF time, but when filling the URBs. Avoiding it will be pretty difficult, as the driver needs to add packet headers. I would leave that out for now. Regarding videobuf2 support, the main issue comes from race conditions between stream start, buffer queueing and URB completion. Unlike the UVC host driver where URBs can be resubmitted immediately, the gadget driver can only resubmit URBs (in uvc_video_complete()) when there is data to be sent. Otherwise the URB is put on a free URBs list (video-req_free) and enqueued in uvc_video_pump() the next time a buffer is queued. This requires taking various locks and must thus be considered with care. I'm pretty unhappy with calling video-encode with the queue irqlock held, I would like to change that, but I don't expect to to be an easy task. -- 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: UVCvideo: Failed to resubmit video URB (-27) with Linux 3.3.3
Hi Anisse, On Thursday 26 April 2012 20:07:21 Anisse Astier wrote: Hi, I'm experiencing a problem with uvcvideo with kernel 3.3.3 and today's Linus' tree. Problem not reproduced in 3.2.15, so this could be labelled as a regression. See webcam lsusb and (verbose!) dmesg log in attachment, which exhibits the problem. We see lots of error (-18 = -EXDEV), that indicate that URB was too late and then dropped, and they add up until we reach the Failed to resubmit video URB scheduling issue. Those are USB controller issues. The uvcvideo driver submits URBs with the URB_ISO_ASAP transfer flag, so the controller should not fail to schedule them. Installed libv4l version is 0.8.6. I'm reproducing this with: gst-launch-0.10 --verbose v4l2src ! xvimagesink (Skype exhibits the problem too, while it isn't using gstreamer, so it really seems to come from kernel. Also, doesn't happen with 3.2) This is the first part of the problem. The second part is that if I restart the webcam with gst-launch after the first failure, I have a total freeze, just after these messages in the log (fetched with netconsole, I wasn't able to get a panic trace): [ 191.796217] uvcvideo: Marking buffer as bad (error bit set). [ 191.796233] uvcvideo: Marking buffer as bad (error bit set). [ 191.796244] uvcvideo: Marking buffer as bad (error bit set). [ 191.796252] uvcvideo: Marking buffer as bad (error bit set). [ 191.796259] uvcvideo: Frame complete (EOF found). [ 191.796265] uvcvideo: EOF in empty payload. [ 192.972803] uvcvideo: Marking buffer as bad (error bit set). [ 192.972818] uvcvideo: Dropping payload (out of sync). [ 194.289463] uvcvideo: Marking buffer as bad (error bit set). [ 194.289478] uvcvideo: Frame complete (FID bit toggled). [ 194.289486] uvcvideo: Marking buffer as bad (error bit set). [ 194.289493] uvcvideo: Frame complete (FID bit toggled). [ 194.289499] uvcvideo: Marking buffer as bad (error bit set). [ 194.289505] uvcvideo: Frame complete (FID bit toggled). [ 194.289511] uvcvideo: Marking buffer as bad (error bit set). [ 194.289518] uvcvideo: Frame complete (FID bit toggled). [ 194.289524] uvcvideo: Marking buffer as bad (error bit set). [ 194.289531] uvcvideo: Frame complete (FID bit toggled). Last but not least, uvcvideo is un-bisectable because there were a few crash-fixes during the 3.3 development cycle. I started bisecting and got kernel panics. Are the kernel panics related to uvcvideo ? There's one known bug introduced between v3.2 and v3.3 and fixed (before v3.3) in commit 8e57dec0454d8a3ba987d18b3ab19922c766d4bc. -- 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
[PATCH v3 1/1] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
Remove input field in struct v4l2_buffer and flag V4L2_BUF_FLAG_INPUT which tells the former is valid. The flag is used by no driver currently. Also change the documentation accordingly. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Hi, This is the third version of the v4l2_buffer.input field removal patch. What has changed since the previous version: - Rename input as reserved2 instead of combining it to reserved and making it an array. - cpia compile fix. - Change documentation accordingly. Documentation/DocBook/media/v4l/compat.xml |6 ++ Documentation/DocBook/media/v4l/io.xml | 19 +-- Documentation/DocBook/media/v4l/vidioc-qbuf.xml |9 +++-- drivers/media/video/cpia2/cpia2_v4l.c |2 +- drivers/media/video/v4l2-compat-ioctl32.c | 11 +-- drivers/media/video/videobuf-core.c | 16 drivers/media/video/videobuf2-core.c|5 ++--- include/linux/videodev2.h |3 +-- 8 files changed, 23 insertions(+), 48 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 87339b2..b939457 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2422,6 +2422,12 @@ details./para VIDIOC-SUBDEV-G-SELECTION; and VIDIOC-SUBDEV-S-SELECTION;./para /listitem + listitem + paraReplaced structfieldinput/structfield in + structnamev4l2_buffer/structname by + structfieldreserved2/structfield and removed + constantV4L2_BUF_FLAG_INPUT/constant./para + /listitem /orderedlist /section diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index b815929..e4cb063 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -681,14 +681,12 @@ memory, set by the application. See xref linkend=userp / for details. /row row entry__u32/entry - entrystructfieldinput/structfield/entry + entrystructfieldreserved2/structfield/entry entry/entry - entrySome video capture drivers support rapid and -synchronous video input changes, a function useful for example in -video surveillance applications. For this purpose applications set the -constantV4L2_BUF_FLAG_INPUT/constant flag, and this field to the -number of a video input as in v4l2-input; field -structfieldindex/structfield./entry + entryA place holder for future extensions and custom +(driver defined) buffer types +constantV4L2_BUF_TYPE_PRIVATE/constant and higher. Applications +should set this to 0./entry /row row entry__u32/entry @@ -921,13 +919,6 @@ Drivers set or clear this flag when the constantVIDIOC_DQBUF/constant ioctl is called./entry /row row - entryconstantV4L2_BUF_FLAG_INPUT/constant/entry - entry0x0200/entry - entryThe structfieldinput/structfield field is valid. -Applications set or clear this flag before calling the -constantVIDIOC_QBUF/constant ioctl./entry - /row - row entryconstantV4L2_BUF_FLAG_PREPARED/constant/entry entry0x0400/entry entryThe buffer has been prepared for I/O and can be queued by the diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 9caa49a..77ff5be 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -71,12 +71,9 @@ initialize the structfieldbytesused/structfield, structfieldfield/structfield and structfieldtimestamp/structfield fields, see xref linkend=buffer / for details. -Applications must also set structfieldflags/structfield to 0. If a driver -supports capturing from specific video inputs and you want to specify a video -input, then structfieldflags/structfield should be set to -constantV4L2_BUF_FLAG_INPUT/constant and the field -structfieldinput/structfield must be initialized to the desired input. -The structfieldreserved/structfield field must be set to 0. When using +Applications must also set structfieldflags/structfield to 0. +The structfieldreserved2/structfield and +structfieldreserved/structfield fields must be set to 0. When using the link linkend=planar-apismulti-planar API/link, the structfieldm.planes/structfield field must contain a userspace pointer to a filled-in array of v4l2-plane; and the structfieldlength/structfield diff --git a/drivers/media/video/cpia2/cpia2_v4l.c b/drivers/media/video/cpia2/cpia2_v4l.c index 077eb1d..c105612 100644 --- a/drivers/media/video/cpia2/cpia2_v4l.c +++ b/drivers/media/video/cpia2/cpia2_v4l.c @@ -1289,7 +1289,7 @@ static int cpia2_dqbuf(struct file *file,
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: Hi Paulo, I am running plain Fedora 16 on x86_64. The last kernel where UVC dyncontrols worked was 3.1.10-2. (If I remember correctly...) The first kernel with failing dyncontrols was 3.2.1-1 and all later kernels up to 3.3.2-6 fail as well. libwebcam version is libwebcam-0.2.0-4.20100322svn and guvcview is guvcview-1.5.1-1. http://www.quickcamteam.net/software/libwebcam seems to be offline/ discontinued since a few months. what software versions are you running? Is there a later libwebcam available from somewhere else? pls look also at: http://permalink.gmane.org/gmane.linux.kernel/1257500 Greetings, Karl On Wed 120502, Paulo Assis wrote: Karl Hi, I'm using a 3.2 kernel and I haven't notice this problem, can you check the exact version that causes it. Regards, Paulo -- 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: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
On Wed 120502, Paulo Assis wrote: karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Very much appreciated, Paulo! In the meantime I poked around at Ubuntu and found libwebcam_0.2.1.orig.tar.gz - will try to compiled it but they have a couple of kernel patches to 3.2.x as well and perhaps there is a depency. Karl Regards, Paulo -- 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
HVR-1800 Analog Driver: MPEG video broken
I have been testing the latest cx23885 driver built from http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git;a=summary running on kernel 3.3.4 with my HVR-1800 (model 78521). I am able to watch analog TV with tvtime using the raw device, /dev/video0. But if I try to use it with the MPEG device, /dev/video1, I briefly get a blue screen and then tvtime segfaults. cat /dev/video1 /tmp/foo.mpg gives video with moving, distorted, mostly black and white diagonal lines just like @Britney posted here: http://www.kernellabs.com/blog/?p=1636. My dmesg shows video0 being set up like this: [8.697567] cx23885[0]: registered device video0 [v4l2] [8.697647] cx23885[0]: registered device vbi0 [8.697840] cx23885[0]: registered ALSA audio device and video1 like this: [9.779115] cx23885[0]: registered device video1 [mpeg] [9.779133] Firmware and/or mailbox pointer not initialized or corrupted, signature = 0xd857f5e9, cmd = PING_FW Could the broken MPEG video be related to this firmware error? I am using firmware from here: http://steventoth.net/linux/hvr1800/ BTW, digital video works fine on this card. Jonathan -- 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: SoC i.mx35 userptr method failure while running capture-example utility
Hi Guennadi,
Thanks for your quick response.
./capture-example -u -f -d /dev/video0
mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0
Failed acquiring VMA for vaddr 0x76cd9008
VIDIOC_QBUF error 22, Invalid arg
It doesn't surprise me, that this doesn't work. capture-example allocates
absolutely normal user-space buffers, when called with USERPTR, and those
buffers are very likely discontiguous. Whereas mx3-camera needs physically
contiguous buffers, so, this can only fail. This means, you either have to
use MMAP or you need to allocate USERPTR buffers in a special way to
guarantee their contiguity.
I have a little progress:-)
In thread i.mx35 live video you and Sylvester gave me advice on how to get
the live video
with using the display panning method ... thanks for this invaluable support :-)
I took note of this and I'm currently trying to implement this.
Instead of discontiguous memory allocation I use framebuffer memory allocation
to userspace and this solves the problem.
Now I'm starting to see a live video for 3 seconds, after this video freezes
(it looks like a flickering pause), but the application continues to run
without errors.
can see bellow my strace diagnostic:
ioctl(3, VIDIOC_STREAMON, 0x7ece99f0) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 884508})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 919066})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 918928})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
[snip]
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 87})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 88})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
I do not understand what's the problem, maybe need to implement
FBIO_WAITFORVSYNC ioctl for mx3fb ?
Thanks,
Alex
--
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: HVR-1800 Analog Driver: MPEG video broken
On Wed, May 2, 2012 at 9:32 AM, sitten74...@mypacks.net wrote: I have been testing the latest cx23885 driver built from http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git;a=summary running on kernel 3.3.4 with my HVR-1800 (model 78521). I am able to watch analog TV with tvtime using the raw device, /dev/video0. But if I try to use it with the MPEG device, /dev/video1, I briefly get a blue screen and then tvtime segfaults. Tvtime segfaulting if you try to use it on an MPEG device is a known tvtime bug. Tvtime lacks an MPEG decoder, and only works with devices that support raw video. cat /dev/video1 /tmp/foo.mpg gives video with moving, distorted, mostly black and white diagonal lines just like @Britney posted here: http://www.kernellabs.com/blog/?p=1636. Yup, I've been going back and forth with bfransen on this. I received a board last week, and am hoping to debug it this week. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
Error compiling tw68-v2 module (module_param / linux3.2)
I'm having problems compiling the tw68-v2. I looked up the code from the error messages, but I don't know anything about making linux driver modules. I can't find a lot about the module_param function, at least, not why this would be wrong. Can anyone give any comment on this? Thanks in advance! Linux tkpc 3.2.0-2-amd64 #1 SMP Sun Mar 4 22:48:17 UTC 2012 x86_64 GNU/Linux make -C /lib/modules/3.2.0-2-amd64/build M=/mnt/nfs/black/hw/tw68-v2 modules make[1]: Entering directory `/usr/src/linux-headers-3.2.0-2-amd64' CC [M] /mnt/nfs/black/hw/tw68-v2/tw68-video.o /mnt/nfs/black/hw/tw68-v2/tw68-video.c:42:27: error: expected ‘)’ before ‘int’ /mnt/nfs/black/hw/tw68-v2/tw68-video.c:43:31: error: expected ‘)’ before string constant /mnt/nfs/black/hw/tw68-v2/tw68-video.c:44:24: error: expected ‘)’ before ‘int’ /mnt/nfs/black/hw/tw68-v2/tw68-video.c:45:28: error: expected ‘)’ before string constant /mnt/nfs/black/hw/tw68-v2/tw68-video.c:46:29: error: expected ‘)’ before ‘int’ /mnt/nfs/black/hw/tw68-v2/tw68-video.c:47:33: error: expected ‘)’ before string constant /mnt/nfs/black/hw/tw68-v2/tw68-video.c:48:35: error: expected ‘)’ before ‘sizeof’ /mnt/nfs/black/hw/tw68-v2/tw68-video.c:49:25: error: expected ‘)’ before string constant module_param(video_debug, int, 0644); MODULE_PARM_DESC(video_debug, enable debug messages [video]); module_param(gbuffers, int, 0444); MODULE_PARM_DESC(gbuffers, number of capture buffers, range 2-32); module_param(noninterlaced, int, 0644); MODULE_PARM_DESC(noninterlaced, capture non interlaced video); module_param_string(secam, secam, sizeof(secam), 0644); MODULE_PARM_DESC(secam, force SECAM variant, either DK,L or Lc); -- 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: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
Hi, yes, libwebcam depends on uvcvideo.h, I've only added this as a patch since it was missing from debian kernel headers at the time. I think you should be able to get it from there now, not sure if the new header breaks anything, I'll have to run some tests. The other patches are not needed, but they do increase functionality to some extent. Anyway if this was just a libwebcam issue, guvcview should still be able to add the controls, and apparently that's failing also. Best regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: On Wed 120502, Paulo Assis wrote: karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Very much appreciated, Paulo! In the meantime I poked around at Ubuntu and found libwebcam_0.2.1.orig.tar.gz - will try to compiled it but they have a couple of kernel patches to 3.2.x as well and perhaps there is a depency. Karl Regards, Paulo -- 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/10] dvb-demux: add functionality to send raw payload to the dvr device
On Wed, May 2, 2012 at 7:38 AM, Patrick Boettcher pboettc...@kernellabs.com wrote: Hi Mike, On Tuesday 01 May 2012 06:12:22 Michael Krufky wrote: From: Michael Krufky mkru...@kernellabs.com If your driver needs to deliver the raw payload to userspace without passing through the kernel demux, use function: dvb_dmx_swfilter_raw I like this one very much. I had a background task sleeping in my head which was how to add non-Transport-Stream standards to Linux-dvb. This one I can now cancel, thanks to this change. We now can add CMMB-support and DAB to linux-dvb (after more discussions on the API of course). Do you have user-space-tool ready which uses the new RAW-payload mechanism? Something which can be used as an example. Thanks for this development. -- Patrick Thanks for your support, Patrick. I am working on a bunch of utilities for ATSC-MH, so far I have shown a simple scanning utility, and I plan to release additional utilities for parsing the data soon. The way it works, since we are using the delivery_system == SYS_ATSCMH, we know that the payload should be parsed as ATSCMH. Likewise, when delivery_system == SYS_CMMB, we will parse it as CMMB. We can use this mechanism for delivering any type of non-TS based data stream. Since both CMMB and ATSCMH are IP-based systems, perhaps we can do this parsing in a common library. Do you have any CMMB or ATSCMH devices? -Mike -- 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 v3 00/10] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi everyone, It's been a long time since last version (5 months)! :) This is the third version of the OMAP4 ISS driver, which uses Media Controller and videobuf2 frameworks. This patchset should apply cleanly on top of v3.4-rc5 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A/B interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Changes since v2: - Supports CSI2B now! - Add support for RAW8. - Usage of V4L2_CID_PIXEL_RATE, instead of dphy configuration in boardfile (similar to omap3isp) - Removes save/restore support for now, as it is broken. - Attend several comments form Sakari Ailus (Thanks Sakari!) - Populate hw_revision in media_dev struct. - Ported several fixes pushed for omap3isp (Thanks Laurent!) - Use module_platform_driver. - Use proposed generic v4l2_subdev_link_validate. - Move OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX handle to omap4iss code, instead of board file. Changes since v1: - Simplification of auxclk handlign in board files - Use of HWMOD declaration for assisted platform_device creation. - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) Regards, Sergio Sergio Aguirre (10): mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera omap2plus: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Documentation/video4linux/omap4_camera.txt| 64 ++ arch/arm/configs/omap2plus_defconfig |2 + arch/arm/mach-omap2/Kconfig | 32 + arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-4430sdp-camera.c| 415 arch/arm/mach-omap2/board-4430sdp.c | 20 + arch/arm/mach-omap2/board-omap4panda-camera.c | 209 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/devices.h |4 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 22 +- drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile |3 + drivers/media/video/omap4iss/Makefile |6 + drivers/media/video/omap4iss/iss.c| 1159 + drivers/media/video/omap4iss/iss.h| 121 +++ drivers/media/video/omap4iss/iss_csi2.c | 1368 + drivers/media/video/omap4iss/iss_csi2.h | 155 +++ drivers/media/video/omap4iss/iss_csiphy.c | 281 + drivers/media/video/omap4iss/iss_csiphy.h | 51 + drivers/media/video/omap4iss/iss_regs.h | 244 + drivers/media/video/omap4iss/iss_video.c | 1123 drivers/media/video/omap4iss/iss_video.h | 201 drivers/media/video/ov5640.c | 948 + drivers/media/video/ov5650.c | 733 + include/linux/mfd/twl6040.h |2 +- include/media/omap4iss.h | 65 ++ include/media/ov5640.h| 10 + include/media/ov5650.h| 10 + 28 files changed, 7314 insertions(+), 2 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode 100644 include/media/omap4iss.h create mode 100644 include/media/ov5640.h create mode 100644 include/media/ov5650.h -- 1.7.5.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
[PATCH v3 01/10] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
The define should be the result of 1 Bit number. Bit number for GPOCTL.GPO3 field is 2, which results in 0x4 value. Signed-off-by: Sergio Aguirre saagui...@ti.com --- include/linux/mfd/twl6040.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index b15b5f0..df86c14 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -142,7 +142,7 @@ #define TWL6040_GPO1 0x01 #define TWL6040_GPO2 0x02 -#define TWL6040_GPO3 0x03 +#define TWL6040_GPO3 0x04 /* ACCCTL (0x2D) fields */ -- 1.7.5.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
[PATCH v3 03/10] OMAP4: Add base addresses for ISS
NOTE: This isn't the whole list of features that the
ISS supports, but the only ones supported at the moment.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/devices.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index e433603..2b8cf73 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/platform_data/omap4-keypad.h
+#include media/omap4iss.h
+
#include mach/hardware.h
#include mach/irqs.h
#include asm/mach-types.h
@@ -236,6 +238,36 @@ int omap3_init_camera(struct isp_platform_data *pdata)
#endif
+int omap4_init_camera(struct iss_platform_data *pdata, struct omap_board_data
*bdata)
+{
+ struct platform_device *pdev;
+ struct omap_hwmod *oh;
+ struct iss_platform_data *omap4iss_pdata;
+ const char *oh_name = iss;
+ const char *name = omap4iss;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name);
+ return -ENODEV;
+ }
+
+ omap4iss_pdata = pdata;
+
+ pdev = omap_device_build(name, -1, oh, omap4iss_pdata,
+ sizeof(struct iss_platform_data), NULL, 0, 0);
+
+ if (IS_ERR(pdev)) {
+ WARN(1, Can't build omap_device for %s:%s.\n,
+ name, oh-name);
+ return PTR_ERR(pdev);
+ }
+
+ oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
+
+ return 0;
+}
+
static inline void omap_init_camera(void)
{
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
--
1.7.5.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
[PATCH v3 02/10] OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections
In memory, They are in this particular order:
- CSI2A
- CSIPHY1
- CSI2B
- CSIPHY2
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6abc757..a7b2380 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2641,6 +2641,26 @@ static struct omap_hwmod_addr_space omap44xx_iss_addrs[]
= {
.pa_end = 0x52ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x52001000,
+ .pa_end = 0x5200116f,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = 0x52001170,
+ .pa_end = 0x5200118f,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = 0x52001400,
+ .pa_end = 0x5200156f,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = 0x52001570,
+ .pa_end = 0x5200158f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
@@ -5605,7 +5625,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_ipu_c1_hwmod,
/* iss class */
-/* omap44xx_iss_hwmod, */
+ omap44xx_iss_hwmod,
/* iva class */
omap44xx_iva_hwmod,
--
1.7.5.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
[PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig| 16 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-4430sdp-camera.c | 415
arch/arm/mach-omap2/board-4430sdp.c| 20 ++
4 files changed, 453 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8141b76..54645aa 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -335,6 +335,22 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+config MACH_OMAP_4430SDP_CAMERA_SUPPORT
+ bool OMAP 4430 SDP board Camera support
+ depends on MACH_OMAP_4430SDP
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L_PLATFORM_DRIVERS
+ select VIDEO_OMAP4
+ select VIDEO_OV5640
+ select VIDEO_OV5650
+ help
+ Enable Camera HW support for OMAP 4430 SDP board
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..ebd8f63 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -239,6 +239,8 @@ obj-$(CONFIG_MACH_TI8148EVM)+=
board-ti8168evm.o
# Platform specific device init code
+obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) += board-4430sdp-camera.o
+
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
obj-y += $(omap-flash-y) $(omap-flash-m)
diff --git a/arch/arm/mach-omap2/board-4430sdp-camera.c
b/arch/arm/mach-omap2/board-4430sdp-camera.c
new file mode 100644
index 000..9a8881f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-4430sdp-camera.c
@@ -0,0 +1,415 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
+#include linux/regulator/consumer.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
+#include control.h
+#include mux.h
+
+#define OMAP4430SDP_GPIO_CAM_PDN_B 38
+#define OMAP4430SDP_GPIO_CAM_PDN_C 39
+
+static struct clk *sdp4430_cam1_aux_clk;
+static struct clk *sdp4430_cam2_aux_clk;
+static struct regulator *sdp4430_cam2pwr_reg;
+
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power regulator
'cam2pwr'\n);
+ return ret;
+ }
+
+
[PATCH v3 05/10] v4l: Add support for ov5640 sensor
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/ov5640.c | 948 ++
include/media/ov5640.h | 10 +
4 files changed, 965 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4482ac4..cc76652 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -480,6 +480,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c95cc0d..da40ab3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..2a64d50
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,948 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5640.h
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_colorspacecolorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST] = {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5640_SIZE_LAST; i++) {
+ if ((ov5640_frmsizes[i].width = width)
+ (ov5640_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5640_SIZE_LAST)
+ i = OV5640_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5640 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov5640_platform_data *pdata;
+
+ struct v4l2_ctrl *pixel_rate;
+};
+
+static inline struct ov5640 *to_ov5640(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5640, subdev);
+}
+
+/**
+ * struct ov5640_reg - ov5640 register format
+ * @reg: 16-bit offset to register
+ * @val: 8/16/32-bit register value
+ * @length: length of the register
+ *
+ * Define a structure for OV5640 register initialization values
+ */
+struct ov5640_reg {
+ u16 reg;
+ u8 val;
+};
+
+/* TODO: Divide this properly */
+static const struct ov5640_reg configscript_common1[] = {
+
[PATCH v3 08/10] arm: omap4panda: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 16 ++
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda-camera.c | 209 +
3 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 54645aa..4b267a6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -359,6 +359,22 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+config MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ bool OMAP4 Panda Board Camera support
+ depends on MACH_OMAP4_PANDA
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select V4L_PLATFORM_DRIVERS
+ select VIDEO_OMAP4
+ select VIDEO_OV5640
+ select VIDEO_OV5650
+ help
+ Enable Camera HW support for PandaBoard.
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ebd8f63..e6724c4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -240,6 +240,7 @@ obj-$(CONFIG_MACH_TI8148EVM)+=
board-ti8168evm.o
# Platform specific device init code
obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) += board-4430sdp-camera.o
+obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT) += board-omap4panda-camera.o
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
b/arch/arm/mach-omap2/board-omap4panda-camera.c
new file mode 100644
index 000..a5f7863
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
@@ -0,0 +1,209 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
+#include control.h
+#include mux.h
+
+#define PANDA_GPIO_CAM_PWRDN 45
+#define PANDA_GPIO_CAM_RESET 83
+
+static struct clk *panda_cam_aux_clk;
+
+static int panda_ov_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+
+ if (on) {
+ int ret;
+
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 0);
+ ret = clk_enable(panda_cam_aux_clk);
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 1);
+ return ret;
+ }
+ mdelay(2);
+ } else {
+ clk_disable(panda_cam_aux_clk);
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 1);
+ }
+
+ return 0;
+}
+
+#define OV5640_I2C_ADDRESS (0x3C)
+
+static struct ov5640_platform_data ov5640_platform_data = {
+ .s_power = panda_ov_power,
+};
+
+static struct i2c_board_info ov5640_camera_i2c_device = {
+ I2C_BOARD_INFO(ov5640, OV5640_I2C_ADDRESS),
+ .platform_data = ov5640_platform_data,
+};
+
+#define OV5650_I2C_ADDRESS (0x36)
+
+static struct ov5650_platform_data ov5650_platform_data = {
+ .s_power = panda_ov_power,
+};
+
+static struct i2c_board_info ov5650_camera_i2c_device = {
+ I2C_BOARD_INFO(ov5650, OV5650_I2C_ADDRESS),
+ .platform_data = ov5650_platform_data,
+};
+
+static struct iss_subdev_i2c_board_info ov5640_camera_subdevs[] = {
+ {
+ .board_info = ov5640_camera_i2c_device,
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
+static struct iss_subdev_i2c_board_info ov5650_camera_subdevs[] = {
+ {
+ .board_info = ov5650_camera_i2c_device,
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
+static struct iss_v4l2_subdevs_group panda_camera_subdevs[] = {
+ {
+ .subdevs = ov5640_camera_subdevs,
+ .interface = ISS_INTERFACE_CSI2A_PHY1,
+ .bus = { .csi2 = {
+ .lanecfg= {
+ .clk = {
+ .pol = 0,
+ .pos = 1,
+ },
+ .data[0] = {
+ .pol = 0,
+ .pos = 2,
+
[PATCH v3 09/10] omap2plus: Add support for omap4iss camera
Also add support for following sensors: - OV5640 - OV5650 Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..ea7e8e9 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -23,6 +23,8 @@ CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_ARCH_OMAP=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT=y +CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y -- 1.7.5.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
[PATCH v3 10/10] arm: Add support for CMA for omap4iss driver
Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/mach-omap2/devices.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 2b8cf73..5259691 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -18,6 +18,9 @@ #include linux/slab.h #include linux/of.h #include linux/platform_data/omap4-keypad.h +#ifdef CONFIG_CMA +#include linux/dma-contiguous.h +#endif #include media/omap4iss.h @@ -265,6 +268,11 @@ int omap4_init_camera(struct iss_platform_data *pdata, struct omap_board_data *b oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt); +#ifdef CONFIG_CMA + /* Create private 32MiB contiguous memory area for omap4iss device */ + dma_declare_contiguous(pdev-dev, 32*SZ_1M, 0, 0); +#endif + return 0; } -- 1.7.5.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
[PATCH v3 06/10] v4l: Add support for ov5650 sensor
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile |1 +
drivers/media/video/ov5650.c | 733 ++
include/media/ov5650.h | 10 +
4 files changed, 750 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5650.c
create mode 100644 include/media/ov5650.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index cc76652..e4d1875 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -486,6 +486,12 @@ config VIDEO_OV5640
help
This is a ov5640 camera driver
+config VIDEO_OV5650
+ tristate OmniVision OV5650 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5650 camera driver
+
config VIDEO_VS6624
tristate ST VS6624 sensor support
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index da40ab3..01945c1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
+obj-$(CONFIG_VIDEO_OV5650) += ov5650.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/video/ov5650.c b/drivers/media/video/ov5650.c
new file mode 100644
index 000..33ab148
--- /dev/null
+++ b/drivers/media/video/ov5650.c
@@ -0,0 +1,733 @@
+/*
+ * OmniVision OV5650 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+#include media/v4l2-ctrls.h
+
+#include media/ov5650.h
+
+/* OV5650 has only one fixed colorspace per pixelcode */
+struct ov5650_datafmt {
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_colorspacecolorspace;
+};
+
+enum ov5650_size {
+ OV5650_SIZE_5MP,
+ OV5650_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5650_frmsizes[OV5650_SIZE_LAST] = {
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5650_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5650_SIZE_LAST; i++) {
+ if ((ov5650_frmsizes[i].width = width)
+ (ov5650_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5650_SIZE_LAST)
+ i = OV5650_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5650 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+
+ struct v4l2_mbus_framefmt format;
+
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ const struct ov5650_platform_data *pdata;
+
+ struct v4l2_ctrl *pixel_rate;
+};
+
+static inline struct ov5650 *to_ov5650(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5650, subdev);
+}
+
+/**
+ * struct ov5650_reg - ov5650 register format
+ * @reg: 16-bit offset to register
+ * @val: 8/16/32-bit register value
+ * @length: length of the register
+ *
+ * Define a structure for OV5650 register initialization values
+ */
+struct ov5650_reg {
+ u16 reg;
+ u8 val;
+};
+
+static const struct ov5650_reg configscript_common1[] = {
+ { 0x3103, 0x93 },
+ { 0x3b07, 0x0c },
+ { 0x3017, 0xff },
+ { 0x3018, 0xfc },
+ { 0x3706, 0x41 },
+ { 0x3703, 0xe6 },
+ { 0x3613, 0x44 },
+ { 0x3630, 0x22 },
+ { 0x3605, 0x04 },
+ { 0x3606, 0x3f },
+ { 0x3712, 0x13 },
+ { 0x370e, 0x00 },
+ { 0x370b, 0x40 },
+ { 0x3600, 0x54 },
+ { 0x3601, 0x05 },
+ { 0x3713, 0x22 },
+ { 0x3714, 0x27 },
+ { 0x3631, 0x22 },
+ { 0x3612, 0x1a },
+ { 0x3604, 0x40 },
+ { 0x3705, 0xda },
+ { 0x370a, 0x80 },
+ { 0x370c, 0x00 },
+ { 0x3710, 0x28 },
+ { 0x3702, 0x3a },
+ { 0x3704, 0x18 },
+ { 0x3a18, 0x00 },
+ { 0x3a19, 0xf8 },
+ { 0x3a00, 0x38 },
+};
+
+static const struct ov5650_reg configscript_common2[] = {
+ { 0x3a08, 0x12 },
+ { 0x3a09, 0x70 },
+ { 0x3a0a, 0x0f },
+ {
Re: [PATCH v3 00/10] v4l2: OMAP4 ISS driver + Sensor + Board support
On Wed, May 2, 2012 at 10:15 AM, Sergio Aguirre saagui...@ti.com wrote: Hi everyone, It's been a long time since last version (5 months)! :) This is the third version of the OMAP4 ISS driver, which uses Media Controller and videobuf2 frameworks. This patchset should apply cleanly on top of v3.4-rc5 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A/B interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Apologies, forgot to mention this: Tested with these patchsets: - Sakari's patches for N9 and some v4l2 changes: http://www.spinics.net/lists/linux-media/msg45052.html - CMA v24: http://www.spinics.net/lists/linux-media/msg46106.html Both rebased to v3.4-rc5. Regards, Sergio Changes since v2: - Supports CSI2B now! - Add support for RAW8. - Usage of V4L2_CID_PIXEL_RATE, instead of dphy configuration in boardfile (similar to omap3isp) - Removes save/restore support for now, as it is broken. - Attend several comments form Sakari Ailus (Thanks Sakari!) - Populate hw_revision in media_dev struct. - Ported several fixes pushed for omap3isp (Thanks Laurent!) - Use module_platform_driver. - Use proposed generic v4l2_subdev_link_validate. - Move OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_CAMERA_RX handle to omap4iss code, instead of board file. Changes since v1: - Simplification of auxclk handlign in board files - Use of HWMOD declaration for assisted platform_device creation. - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) Regards, Sergio Sergio Aguirre (10): mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A/B and CSIPHY1/2 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera omap2plus: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Documentation/video4linux/omap4_camera.txt | 64 ++ arch/arm/configs/omap2plus_defconfig | 2 + arch/arm/mach-omap2/Kconfig | 32 + arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/board-4430sdp-camera.c | 415 arch/arm/mach-omap2/board-4430sdp.c | 20 + arch/arm/mach-omap2/board-omap4panda-camera.c | 209 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/devices.h | 4 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 22 +- drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile | 3 + drivers/media/video/omap4iss/Makefile | 6 + drivers/media/video/omap4iss/iss.c | 1159 + drivers/media/video/omap4iss/iss.h | 121 +++ drivers/media/video/omap4iss/iss_csi2.c | 1368 + drivers/media/video/omap4iss/iss_csi2.h | 155 +++ drivers/media/video/omap4iss/iss_csiphy.c | 281 + drivers/media/video/omap4iss/iss_csiphy.h | 51 + drivers/media/video/omap4iss/iss_regs.h | 244 + drivers/media/video/omap4iss/iss_video.c | 1123 drivers/media/video/omap4iss/iss_video.h | 201 drivers/media/video/ov5640.c | 948 + drivers/media/video/ov5650.c | 733 + include/linux/mfd/twl6040.h | 2 +- include/media/omap4iss.h | 65 ++ include/media/ov5640.h | 10 + include/media/ov5650.h | 10 + 28 files changed, 7314 insertions(+), 2 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode
Re: logitech quickcam 9000 uvcdynctrl broken since kernel 3.2 - PING
OK, so UVCIOC_CTRL_ADD is no longer available, now we have: UVCIOC_CTRL_MAP and UVCIOC_CTRL_QUERY, so I guess some changes are needed, I'll try to fix this ASAP. Regards, Paulo 2012/5/2 Paulo Assis pj.as...@gmail.com: Hi, yes, libwebcam depends on uvcvideo.h, I've only added this as a patch since it was missing from debian kernel headers at the time. I think you should be able to get it from there now, not sure if the new header breaks anything, I'll have to run some tests. The other patches are not needed, but they do increase functionality to some extent. Anyway if this was just a libwebcam issue, guvcview should still be able to add the controls, and apparently that's failing also. Best regards, Paulo 2012/5/2 Karl Kiniger karl.kini...@med.ge.com: On Wed 120502, Paulo Assis wrote: karl, I've run some tests under ubuntu 12.04 with kernel 3.2.0 and everything seems to be working fine. I know some changes were made to the uvcvideo module regarding XU controls, but I was under the impression that they wouldn't break userspace. Logitech shutdown the quickcamteam site, so you won't be able to download libwebcam from there. I'm currently the debian mantainer of that package, so I'll try to test it on a newer kernel and patch it as necessary. I'll also fix guvcview if needed. Very much appreciated, Paulo! In the meantime I poked around at Ubuntu and found libwebcam_0.2.1.orig.tar.gz - will try to compiled it but they have a couple of kernel patches to 3.2.x as well and perhaps there is a depency. Karl Regards, Paulo -- 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: HVR-1800 Analog Driver: MPEG video broken
In case it might be helpful, here's the output of v4l2-ctl -d /dev/video1 --log-status: http://pastebin.com/4iTcXDNP Thanks, Jonathan -Original Message- From: Devin Heitmueller dheitmuel...@kernellabs.com Sent: May 2, 2012 9:58 AM To: sitten74...@mypacks.net Cc: linux-media@vger.kernel.org Subject: Re: HVR-1800 Analog Driver: MPEG video broken On Wed, May 2, 2012 at 9:32 AM, sitten74...@mypacks.net wrote: I have been testing the latest cx23885 driver built from http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git;a=summary running on kernel 3.3.4 with my HVR-1800 (model 78521). I am able to watch analog TV with tvtime using the raw device, /dev/video0. But if I try to use it with the MPEG device, /dev/video1, I briefly get a blue screen and then tvtime segfaults. Tvtime segfaulting if you try to use it on an MPEG device is a known tvtime bug. Tvtime lacks an MPEG decoder, and only works with devices that support raw video. cat /dev/video1 /tmp/foo.mpg gives video with moving, distorted, mostly black and white diagonal lines just like @Britney posted here: http://www.kernellabs.com/blog/?p=1636. Yup, I've been going back and forth with bfransen on this. I received a board last week, and am hoping to debug it this week. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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 May 2 19:00:16 CEST 2012 git hash:bcb2cf6e0bf033d79821c89e5ccb328bfbd44907 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: OK linux-3.1-i686: OK linux-3.2.1-i686: OK linux-3.3-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS 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 V4L-DVB specification 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
[RFC v2 0/2] V4L2 IOCTL enum compat wrapper
Hi all,
This is my first intended-to-be-complete RFC patch to get rid of the enums
in V4L2 IOCTL structs. The approach is the one outlined first by Mauro
(AFAIR):
URL:http://www.spinics.net/lists/linux-media/msg46504.html
A set of compat structs (and compat IOCTLs) are created and there are a few
functions to convert between the in-kernel representation and the old
representation with enums the user space may well be using. On many archs
the two IOCTLs are actually the same.
This patchset depends on my earlier patch to remove v4l2_buffer.input:
URL:http://www.spinics.net/lists/linux-media/msg47144.html
All three patches are also available here:
URL:http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/enum-fix
Open questions:
- Orring the return values of {get,put}_user etc. is time-consuming on
modern CPUs with deep pipelines. Would if be better to use | (logical or)
instead? The regular case where the access is successful would be
optimised on the expense of the error case. The end result in error cases
may be different, too, but does that matter?
- Testing this patch completely is difficult. I've only got access to
capture hardware on 32-bit systems which generally do not easily exhibit
problems with enums in IOCTLs (since they're 32-bit ints) in first place.
I've tested this by changing fields from __u32 to __u64 where the old code
had enums; that works, so at least something is working correctly. Help in
testing would be very much appreciated.
Questions and comments are welcome.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
[RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Replace enums in IOCTL structs by __u32. The size of enums is variable and
thus problematic. Compatibility structs having exactly the same as original
definition are provided for compatibility with old binaries with the
required conversion code.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h | 42 +-
include/media/v4l2-ioctl.h | 209
2 files changed, 230 insertions(+), 21 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fed1d40..ec0928d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -292,10 +292,10 @@ struct v4l2_pix_format {
__u32 width;
__u32 height;
__u32 pixelformat;
- enum v4l2_field field;
+ __u32 field; /* enum v4l2_field */
__u32 bytesperline; /* for padding, zero if unused
*/
__u32 sizeimage;
- enum v4l2_colorspacecolorspace;
+ __u32 colorspace; /* enum v4l2_colorspace */
__u32 priv; /* private data, depends on
pixelformat */
};
@@ -432,7 +432,7 @@ struct v4l2_pix_format {
*/
struct v4l2_fmtdesc {
__u32 index; /* Format number */
- enum v4l2_buf_type type; /* buffer type*/
+ __u32 type; /* buffer type (enum
v4l2_buf_type) */
__u32 flags;
__u8description[32]; /* Description string */
__u32 pixelformat; /* Format fourcc */
@@ -573,8 +573,8 @@ struct v4l2_jpegcompression {
*/
struct v4l2_requestbuffers {
__u32 count;
- enum v4l2_buf_type type;
- enum v4l2_memorymemory;
+ __u32 type; /* enum v4l2_buf_type */
+ __u32 memory; /* enum v4l2_memory */
__u32 reserved[2];
};
@@ -636,16 +636,16 @@ struct v4l2_plane {
*/
struct v4l2_buffer {
__u32 index;
- enum v4l2_buf_type type;
+ __u32 type; /* enum v4l2_buf_type */
__u32 bytesused;
__u32 flags;
- enum v4l2_field field;
+ __u32 field; /* enum v4l2_field */
struct timeval timestamp;
struct v4l2_timecodetimecode;
__u32 sequence;
/* memory location */
- enum v4l2_memorymemory;
+ __u32 memory; /* enum v4l2_memory */
union {
__u32 offset;
unsigned long userptr;
@@ -707,7 +707,7 @@ struct v4l2_clip {
struct v4l2_window {
struct v4l2_rectw;
- enum v4l2_field field;
+ __u32 field; /* enum v4l2_field */
__u32 chromakey;
struct v4l2_clip__user *clips;
__u32 clipcount;
@@ -744,14 +744,14 @@ struct v4l2_outputparm {
* I N P U T I M A G E C R O P P I N G
*/
struct v4l2_cropcap {
- enum v4l2_buf_type type;
+ __u32 type; /* enum v4l2_buf_type */
struct v4l2_rectbounds;
struct v4l2_rectdefrect;
struct v4l2_fract pixelaspect;
};
struct v4l2_crop {
- enum v4l2_buf_type type;
+ __u32 type; /* enum v4l2_buf_type */
struct v4l2_rectc;
};
@@ -1156,7 +1156,7 @@ enum v4l2_ctrl_type {
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
struct v4l2_queryctrl {
__u32id;
- enum v4l2_ctrl_type type;
+ __u32type; /* enum v4l2_ctrl_type */
__u8 name[32]; /* Whatever */
__s32minimum; /* Note signedness */
__s32maximum;
@@ -1791,7 +1791,7 @@ enum v4l2_jpeg_chroma_subsampling {
struct v4l2_tuner {
__u32 index;
__u8name[32];
- enum v4l2_tuner_typetype;
+ __u32 type; /* enum v4l2_tuner_type */
__u32 capability;
__u32 rangelow;
__u32 rangehigh;
@@ -1841,14 +1841,14 @@ struct v4l2_modulator {
struct v4l2_frequency {
__u32 tuner;
- enum v4l2_tuner_type type;
+ __u32 type; /* enum v4l2_tuner_type */
__u32
[RFC v3 2/2] v4l: Implement compat functions for enum to __u32 change
Implement compat functions to provide conversion between structs containing
enums and those not. The functions are intended to be removed when the
support for such old binaries is no longer necessary.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/Kconfig | 12 +
drivers/media/video/v4l2-ioctl.c | 684 +-
2 files changed, 687 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f2479c5..949f804 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -7,6 +7,18 @@ config VIDEO_V4L2
depends on VIDEO_DEV VIDEO_V4L2_COMMON
default VIDEO_DEV VIDEO_V4L2_COMMON
+config V4L2_COMPAT
+ bool Compatibility for old binaries
+ depends on VIDEO_V4L2
+ default y
+ ---help---
+ Compatibility code to support binaries compiled with old V4L2
+ IOCTL definitions containing enums that have been replaced by
+ __u32. If you do not need to use such binaries you can disable
+ this option.
+
+ When in doubt, say Y.
+
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 5b2ec1f..9b88360 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2303,6 +2303,653 @@ static long __video_do_ioctl(struct file *file,
return ret;
}
+#ifdef CONFIG_V4L2_COMPAT
+
+static inline unsigned int get_non_compat_cmd(unsigned int cmd)
+{
+ switch (cmd) {
+ case VIDIOC_ENUM_FMT_ENUM:
+ return VIDIOC_ENUM_FMT;
+ case VIDIOC_G_FMT_ENUM:
+ return VIDIOC_G_FMT;
+ case VIDIOC_S_FMT_ENUM:
+ return VIDIOC_S_FMT;
+ case VIDIOC_REQBUFS_ENUM:
+ return VIDIOC_REQBUFS;
+ case VIDIOC_QUERYBUF_ENUM:
+ return VIDIOC_QUERYBUF;
+ case VIDIOC_G_FBUF_ENUM:
+ return VIDIOC_G_FBUF;
+ case VIDIOC_S_FBUF_ENUM:
+ return VIDIOC_S_FBUF;
+ case VIDIOC_QBUF_ENUM:
+ return VIDIOC_QBUF;
+ case VIDIOC_DQBUF_ENUM:
+ return VIDIOC_DQBUF;
+ case VIDIOC_G_PARM_ENUM:
+ return VIDIOC_G_PARM;
+ case VIDIOC_S_PARM_ENUM:
+ return VIDIOC_S_PARM;
+ case VIDIOC_G_TUNER_ENUM:
+ return VIDIOC_G_TUNER;
+ case VIDIOC_S_TUNER_ENUM:
+ return VIDIOC_S_TUNER;
+ case VIDIOC_QUERYCTRL_ENUM:
+ return VIDIOC_QUERYCTRL;
+ case VIDIOC_G_FREQUENCY_ENUM:
+ return VIDIOC_G_FREQUENCY;
+ case VIDIOC_S_FREQUENCY_ENUM:
+ return VIDIOC_S_FREQUENCY;
+ case VIDIOC_CROPCAP_ENUM:
+ return VIDIOC_CROPCAP;
+ case VIDIOC_G_CROP_ENUM:
+ return VIDIOC_G_CROP;
+ case VIDIOC_S_CROP_ENUM:
+ return VIDIOC_S_CROP;
+ case VIDIOC_TRY_FMT_ENUM:
+ return VIDIOC_TRY_FMT;
+ case VIDIOC_G_SLICED_VBI_CAP_ENUM:
+ return VIDIOC_G_SLICED_VBI_CAP;
+ case VIDIOC_S_HW_FREQ_SEEK_ENUM:
+ return VIDIOC_S_HW_FREQ_SEEK;
+ case VIDIOC_CREATE_BUFS_ENUM:
+ return VIDIOC_CREATE_BUFS;
+ case VIDIOC_PREPARE_BUF_ENUM:
+ return VIDIOC_PREPARE_BUF;
+ default:
+ return cmd;
+ }
+}
+
+#define get_user_conv(x, ptr) \
+ ({ \
+ typeof (*ptr) tmp; \
+ int rval; \
+ \
+ rval = get_user(tmp, ptr); \
+ if (!rval) \
+ x = (typeof (x))tmp;\
+ \
+ rval; \
+ })
+
+static int get_user_pix_format(struct v4l2_pix_format *k,
+ struct v4l2_pix_format_enum *u)
+{
+ return get_user(k-width, u-width)
+ || get_user(k-height, u-height)
+ || get_user(k-pixelformat, u-pixelformat)
+ || get_user_conv(k-field, u-field)
+ || get_user(k-bytesperline, u-bytesperline)
+ || get_user(k-sizeimage, u-sizeimage)
+ || get_user_conv(k-colorspace, u-colorspace)
+ || get_user(k-priv, u-priv);
+}
+
+static int get_user_pix_format_mplane(struct v4l2_pix_format_mplane *k,
+ struct v4l2_pix_format_mplane_enum *u)
+{
+ return get_user(k-width, u-width)
+ || get_user(k-height, u-height)
+ || get_user(k-pixelformat, u-pixelformat)
+ || get_user_conv(k-field, u-field)
+ || get_user_conv(k-colorspace, u-colorspace)
+ || copy_from_user(k-plane_fmt, u-plane_fmt,
+
Re: HVR-1800 Analog Driver: MPEG video broken
I just tried again with a live CD running kernel 3.2 and got clean video with cat /dev/video1 /tmp/foo.mpg. So there is a definitely a regression here. Please let me know what I can do to help track it down. Regards, Jonathan -Original Message- From: sitten74...@mypacks.net Sent: May 2, 2012 11:53 AM To: Devin Heitmueller dheitmuel...@kernellabs.com Cc: linux-media@vger.kernel.org Subject: Re: HVR-1800 Analog Driver: MPEG video broken In case it might be helpful, here's the output of v4l2-ctl -d /dev/video1 --log-status: http://pastebin.com/4iTcXDNP Thanks, Jonathan -Original Message- From: Devin Heitmueller dheitmuel...@kernellabs.com Sent: May 2, 2012 9:58 AM To: sitten74...@mypacks.net Cc: linux-media@vger.kernel.org Subject: Re: HVR-1800 Analog Driver: MPEG video broken On Wed, May 2, 2012 at 9:32 AM, sitten74...@mypacks.net wrote: I have been testing the latest cx23885 driver built from http://git.kernellabs.com/?p=stoth/cx23885-hvr1850-fixups.git;a=summary running on kernel 3.3.4 with my HVR-1800 (model 78521). I am able to watch analog TV with tvtime using the raw device, /dev/video0. But if I try to use it with the MPEG device, /dev/video1, I briefly get a blue screen and then tvtime segfaults. Tvtime segfaulting if you try to use it on an MPEG device is a known tvtime bug. Tvtime lacks an MPEG decoder, and only works with devices that support raw video. cat /dev/video1 /tmp/foo.mpg gives video with moving, distorted, mostly black and white diagonal lines just like @Britney posted here: http://www.kernellabs.com/blog/?p=1636. Yup, I've been going back and forth with bfransen on this. I received a board last week, and am hoping to debug it this week. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
Re: [PATCH v3 07/10] arm: omap4430sdp: Add support for omap4iss camera
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+ }
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
+ msleep(10);
+ ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
+ if (ret) {
+ dev_err(dev,
+ Error in clk_enable() in %s(%d)\n,
+ __func__, on);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ return ret;
+ }
+ msleep(10);
+ } else {
+ clk_disable(sdp4430_cam1_aux_clk);
+ msleep(1);
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
+ if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
+ ret = regulator_disable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in disabling sensor power
regulator 'cam2pwr'\n);
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
Isn't this something that should be part of the sensor driver? There's
nothing in the above code that would be board specific, except the names of
the clocks, regulators and GPIOs. The sensor driver could hold the names
instead; this would be also compatible with the device tree.
It should be possible to have s_power() callback NULL, too.
+static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
+{
+ struct device *dev = subdev-v4l2_dev-dev;
+ int ret;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ ret = regulator_enable(sdp4430_cam2pwr_reg);
+ if (ret) {
+ dev_err(dev,
+ Error in enabling sensor power regulator
'cam2pwr'\n);
+ return ret;
+ }
+
+ msleep(50);
+
+ if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
+ if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
+ gpoctl | TWL6040_GPO3,
+ TWL6040_REG_GPOCTL))
+ return -ENODEV;
The above piece of code looks quite interesting. What does it do?
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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: HVR-1800 Analog Driver: MPEG video broken
On Wed, May 2, 2012 at 3:23 PM, sitten74...@mypacks.net wrote: I just tried again with a live CD running kernel 3.2 and got clean video with cat /dev/video1 /tmp/foo.mpg. So there is a definitely a regression here. Please let me know what I can do to help track it down. I'm already about 95% certain this was something introduced in Steven's last batch of cx23885 changes for the HVR-1850. I just need to do a register dump for both the working and failing case, see which register got screwed up on the 1800, then look at the code figure out how it got into that state. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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 v3 1/2] v4l: Do not use enums in IOCTL structs
Hi Hans, On Wed, May 02, 2012 at 10:45:22PM +0200, Hans Verkuil wrote: On Wed May 2 2012 21:13:47 Sakari Ailus wrote: Replace enums in IOCTL structs by __u32. The size of enums is variable and thus problematic. Compatibility structs having exactly the same as original definition are provided for compatibility with old binaries with the required conversion code. Does someone actually have hard proof that there really is a problem? You know, demonstrate it with actual example code? It's pretty horrible that you have to do all those conversions and that code will be with us for years to come. For most (if not all!) architectures sizeof(enum) == sizeof(u32), so there is no need for any compat code for those. Cases I know where this can go wrong are, but there may well be others: - ppc64: int is 64 bits there, and thus also enums, - Enums are quite a different concept in C++ than in C --- the compiler may make assumpton based on the value range of the enums --- videodev2.h should be included with extern C in that case, though, - C does not specify which integer type enums actually use; this is what GCC manual says about it: URL:http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Enumerations So a compiler other than GCC should use 16-bit enums and conform to C while breaking V4L2. This might be a theoretical issue, though. More discussion took place in this thread: URL:http://www.spinics.net/lists/linux-media/msg46167.html Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
[PATCH V3 4/5] [Documentation] Media: Update docs for V4L2 FM new features
From: Manjunatha Halli x0130...@ti.com The list of new features - 1) New control class for FM RX 2) New FM RX CID's - De-Emphasis filter mode and RDS AF switch 3) New FM TX CID - RDS Alternate frequency set. Signed-off-by: Manjunatha Halli x0130...@ti.com --- Documentation/DocBook/media/v4l/compat.xml |3 + Documentation/DocBook/media/v4l/controls.xml | 78 Documentation/DocBook/media/v4l/dev-rds.xml|5 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 ++ .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml|7 ++- 5 files changed, 97 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index bce97c5..df1f345 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2311,6 +2311,9 @@ more information./para paraAdded FM Modulator (FM TX) Extended Control Class: constantV4L2_CTRL_CLASS_FM_TX/constant and their Control IDs./para /listitem listitem + paraAdded FM Receiver (FM RX) Extended Control Class: constantV4L2_CTRL_CLASS_FM_RX/constant and their Control IDs./para + /listitem + listitem paraAdded Remote Controller chapter, describing the default Remote Controller mapping for media devices./para /listitem /orderedlist diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index b84f25e..b6e4db2 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3018,6 +3018,12 @@ to find receivers which can scroll strings sized as 32 x N or 64 x N characters. with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. /entry /row row + entry spanname=idconstantV4L2_CID_RDS_TX_AF_FREQ/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Alternate Frequency value which allows a receiver to re-tune to a different frequency providing the same station when the first signal becomes too weak (e.g., when moving out of range). /entry + /row + row entry spanname=idconstantV4L2_CID_AUDIO_LIMITER_ENABLED/constantnbsp;/entry entryboolean/entry /row @@ -3146,6 +3152,78 @@ manually or automatically if set to zero. Unit, range and step are driver-specif xref linkend=en50067 / document, from CENELEC./para /section +section id=fm-rx-controls + titleFM Receiver Control Reference/title + + paraThe FM Receiver (FM_RX) class includes controls for common features of +FM Reception capable devices. Currently this class includes parameter for Alternate +frequency./para + + table pgwide=1 frame=none id=fm-rx-control-id + titleFM_RX Control IDs/title + + tgroup cols=4 +colspec colname=c1 colwidth=1* / +colspec colname=c2 colwidth=6* / +colspec colname=c3 colwidth=2* / +colspec colname=c4 colwidth=6* / +spanspec namest=c1 nameend=c2 spanname=id / +spanspec namest=c2 nameend=c4 spanname=descr / +thead + row +entry spanname=id align=leftID/entry +entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row +/thead +tbody valign=top + rowentry/entry/row + row +entry spanname=idconstantV4L2_CID_FM_RX_CLASS/constantnbsp;/entry +entryclass/entry + /rowrowentry spanname=descrThe FM_RX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row +entry spanname=idconstantV4L2_CID_RDS_AF_SWITCH/constantnbsp;/entry +entryboolean/entry + /row + rowentry spanname=descrEnable/Disable's FM RX RDS Alternate frequency feature. When enabled driver will decode the RDS AF field and tries to switch to this AF frequency once current frequency RSSI level goes below threshold. Value of G_FREQUENCY is unchanged since both original frequency and AF frequency share the same PI code./entry + /row + row + entry spanname=idconstantV4L2_CID_TUNE_DEEMPHASIS/constantnbsp;/entry + entryinteger/entry + /row + row id=v4l2-deemphasisentry spanname=descrConfigures the de-emphasis value for reception. +A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies. +Depending on the region, a time constant of either 50 or 75 useconds is used. The enumnbsp;v4l2_preemphasis +defines possible values for pre-emphasis. Here they are:/entry + /rowrow + entrytbl spanname=descr cols=2 + tbody valign=top +
[PATCH V3 5/5] [Media] WL12xx: Add support for FM new features.
From: Manjunatha Halli x0130...@ti.com
This patch adds below features to TI's V4l2 FM driver for Wilink
chipsets,
1) FM RX Set frequency allows to set frequency anywhere between
65.5 MHz till 108 MHz (if chip is Wilink8 then till 164.55 MHz)
2) FM RX seek caters for band switch
3) FM RX RDS AF turn ON/OFF
4) FM RX De-Emphasis mode set/get
5) FM TX Alternate Frequency set/get
Also this patch fixes below issues
1) FM audio volume gain setting
2) Default rssi level is set to 8 instead of 20
3) Issue related to audio mute/unmute
4) Enable FM RX AF support in driver
5) In wrap_around seek mode try for once
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
drivers/media/radio/wl128x/fmdrv.h|3 +-
drivers/media/radio/wl128x/fmdrv_common.c | 38 ++---
drivers/media/radio/wl128x/fmdrv_common.h | 28 -
drivers/media/radio/wl128x/fmdrv_rx.c | 90 +++--
drivers/media/radio/wl128x/fmdrv_rx.h |2 +-
drivers/media/radio/wl128x/fmdrv_v4l2.c | 91 +++--
6 files changed, 215 insertions(+), 37 deletions(-)
diff --git a/drivers/media/radio/wl128x/fmdrv.h
b/drivers/media/radio/wl128x/fmdrv.h
index d84ad9d..c806c85 100644
--- a/drivers/media/radio/wl128x/fmdrv.h
+++ b/drivers/media/radio/wl128x/fmdrv.h
@@ -150,6 +150,7 @@ struct fm_rx {
struct region_info region; /* Current selected band */
u32 freq; /* Current RX frquency */
u8 mute_mode; /* Current mute mode */
+ u8 bl_flag; /* Band limit reached flag */
u8 deemphasis_mode; /* Current deemphasis mode */
/* RF dependent soft mute mode */
u8 rf_depend_mute;
@@ -203,7 +204,7 @@ struct fmtx_data {
struct fmdev {
struct video_device *radio_dev; /* V4L2 video device pointer */
struct snd_card *card; /* Card which holds FM mixer controls */
- u16 asci_id;
+ u16 asic_id;
spinlock_t rds_buff_lock; /* To protect access to RDS buffer */
spinlock_t resp_skb_lock; /* To protect access to received SKB */
diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
b/drivers/media/radio/wl128x/fmdrv_common.c
index fcce61a..ac20556 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -44,20 +44,41 @@
/* Region info */
static struct region_info region_configs[] = {
+ /* Super set of all bands */
+ {
+.chanl_space = FM_CHANNEL_SPACING_200KHZ * FM_FREQ_MUL,
+.bot_freq = 65800, /* 87.5 MHz */
+.top_freq = 162550,/* 108 MHz */
+.fm_band = 0,
+},
/* Europe/US */
{
.chanl_space = FM_CHANNEL_SPACING_200KHZ * FM_FREQ_MUL,
.bot_freq = 87500, /* 87.5 MHz */
.top_freq = 108000,/* 108 MHz */
-.fm_band = 0,
+.fm_band = 1,
},
/* Japan */
{
.chanl_space = FM_CHANNEL_SPACING_200KHZ * FM_FREQ_MUL,
.bot_freq = 76000, /* 76 MHz */
.top_freq = 9, /* 90 MHz */
-.fm_band = 1,
+.fm_band = 2,
},
+ /* Russian (OIRT) band */
+ {
+ .chanl_space = FM_CHANNEL_SPACING_50KHZ * FM_FREQ_MUL_RUS,
+ .bot_freq = 65800, /* 65.8 MHz */
+ .top_freq = 74000, /* 74 MHz */
+ .fm_band = 3,
+ },
+ /* Wether Band */
+ {
+ .chanl_space = FM_CHANNEL_SPACING_50KHZ * FM_FREQ_MUL_WB,
+ .bot_freq = 162400, /* 162.4 MHz */
+ .top_freq = 162550, /* 162.55 MHz */
+ .fm_band = 4,
+ }
};
/* Band selection */
@@ -596,7 +617,6 @@ static void fm_irq_handle_flag_getcmd_resp(struct fmdev
*fmdev)
memcpy(fmdev-irq_info.flag, skb-data, fm_evt_hdr-dlen);
fmdev-irq_info.flag = be16_to_cpu(fmdev-irq_info.flag);
- fmdbg(irq: flag register(0x%x)\n, fmdev-irq_info.flag);
/* Continue next function in interrupt handler table */
fm_irq_call_stage(fmdev, FM_HW_MAL_FUNC_IDX);
@@ -702,7 +722,7 @@ static void fm_rdsparse_swapbytes(struct fmdev *fmdev,
* in Dolphin they are in big endian, the parsing of the RDS data
* is chip dependent
*/
- if (fmdev-asci_id != 0x6350) {
+ if (fmdev-asic_id != 0x6350) {
rds_buff = rds_format-data.groupdatabuff.buff[0];
while (index + 1 FM_RX_RDS_INFO_FIELD_MAX) {
byte1 = rds_buff[index];
@@ -1353,11 +1373,13 @@ static int fm_power_up(struct fmdev *fmdev, u8 mode)
sizeof(asic_ver), asic_ver, resp_len))
goto rel;
+ fmdev-asic_id = be16_to_cpu(asic_id);
+
fmdbg(ASIC ID: 0x%x , ASIC Version: %d\n,
- be16_to_cpu(asic_id), be16_to_cpu(asic_ver));
+ fmdev-asic_id, be16_to_cpu(asic_ver));
sprintf(fw_name, %s_%x.%d.bts, FM_FMC_FW_FILE_START,
[PATCH V3 3/5] [Media] Add new CID for FM TX RDS Alternate Frequency
From: Manjunatha Halli x0130...@ti.com
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
drivers/media/video/v4l2-ctrls.c |1 +
include/linux/videodev2.h|1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index e1bba7d..b4ddd6b 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -614,6 +614,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_RDS_TX_PTY: return RDS Program Type;
case V4L2_CID_RDS_TX_PS_NAME: return RDS PS Name;
case V4L2_CID_RDS_TX_RADIO_TEXT:return RDS Radio Text;
+ case V4L2_CID_RDS_TX_AF_FREQ: return RDS Alternate
Frequency;
case V4L2_CID_AUDIO_LIMITER_ENABLED:return Audio Limiter Feature
Enabled;
case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME: return Audio Limiter Release
Time;
case V4L2_CID_AUDIO_LIMITER_DEVIATION: return Audio Limiter
Deviation;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f94acfd..2514658 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1699,6 +1699,7 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_RDS_TX_PTY(V4L2_CID_FM_TX_CLASS_BASE + 3)
#define V4L2_CID_RDS_TX_PS_NAME
(V4L2_CID_FM_TX_CLASS_BASE + 5)
#define V4L2_CID_RDS_TX_RADIO_TEXT (V4L2_CID_FM_TX_CLASS_BASE + 6)
+#define V4L2_CID_RDS_TX_AF_FREQ
(V4L2_CID_FM_TX_CLASS_BASE + 7)
#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 64)
#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME(V4L2_CID_FM_TX_CLASS_BASE + 65)
--
1.7.4.1
--
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 V3 0/5] [Media] Radio: Fixes and New features for FM
From: Manjunatha Halli x0130...@ti.com Mauro and the list, This version 3 of patchset resolves the comments received from Han's on patchset v2. This patchset creates new control class 'V4L2_CTRL_CLASS_FM_RX' for FM RX, introduces 2 new CID's for FM RX and and 1 new CID for FM TX. Also adds 1 field in struct v4l2_hw_freq_seek. This patch adds few new features to TI's FM driver features are listed below, 1) FM TX RDS Support (RT, PS, AF, PI, PTY) 2) FM RX Russian band support 3) FM RX AF set/get 4) FM RX De-emphasis mode set/get Along with new features this patch also fixes few issues in the driver like default rssi level for seek, unnecessory logs etc. Manjunatha Halli (5): [Media] WL128x: Add support for FM TX RDS [Media] New control class and features for FM RX [Media] Add new CID for FM TX RDS Alternate Frequency [Documentation] Media: Update docs for V4L2 FM new features [Media] WL12xx: Add support for FM new features. Documentation/DocBook/media/v4l/compat.xml |3 + Documentation/DocBook/media/v4l/controls.xml | 78 +++ Documentation/DocBook/media/v4l/dev-rds.xml|5 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml|7 +- drivers/media/radio/wl128x/fmdrv.h |3 +- drivers/media/radio/wl128x/fmdrv_common.c | 55 ++-- drivers/media/radio/wl128x/fmdrv_common.h | 43 +- drivers/media/radio/wl128x/fmdrv_rx.c | 92 ++--- drivers/media/radio/wl128x/fmdrv_rx.h |2 +- drivers/media/radio/wl128x/fmdrv_tx.c | 41 +++ drivers/media/radio/wl128x/fmdrv_tx.h |3 +- drivers/media/radio/wl128x/fmdrv_v4l2.c| 138 +++- drivers/media/video/v4l2-ctrls.c | 18 +++ include/linux/videodev2.h | 12 ++- 15 files changed, 430 insertions(+), 77 deletions(-) -- 1.7.4.1 -- 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 V3 2/5] [Media] New control class and features for FM RX
From: Manjunatha Halli x0130...@ti.com
This patch creates new ctrl class for FM RX and adds new CID's for
below FM features,
1) De-Emphasis filter mode
2) RDS AF switch
Also this patch adds a field for band selection in struct v4l2_hw_freq_seek
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
drivers/media/video/v4l2-ctrls.c | 17 +
include/linux/videodev2.h| 11 ++-
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 18015c0..e1bba7d 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -372,6 +372,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
NULL,
};
+ static const char * const tune_deemphasis[] = {
+ No deemphasis,
+ 50 useconds,
+ 75 useconds,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
return mpeg_audio_sampling_freq;
@@ -414,6 +420,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_TUNE_DEEMPHASIS:
+ return tune_deemphasis;
case V4L2_CID_FLASH_LED_MODE:
return flash_led_mode;
case V4L2_CID_FLASH_STROBE_SOURCE:
@@ -644,6 +652,12 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_JPEG_COMPRESSION_QUALITY: return Compression Quality;
case V4L2_CID_JPEG_ACTIVE_MARKER: return Active Markers;
+ /* FM Radio Receiver control */
+ /* Keep the order of the 'case's the same as in videodev2.h! */
+ case V4L2_CID_FM_RX_CLASS: return FM Radio Receiver
Controls;
+ case V4L2_CID_RDS_AF_SWITCH:return FM RX RDS AF switch;
+ case V4L2_CID_TUNE_DEEMPHASIS: return FM RX De-emphasis
settings;
+
default:
return NULL;
}
@@ -688,6 +702,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM:
case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE:
case V4L2_CID_MPEG_VIDEO_MPEG4_QPEL:
+ case V4L2_CID_RDS_AF_SWITCH:
*type = V4L2_CTRL_TYPE_BOOLEAN;
*min = 0;
*max = *step = 1;
@@ -733,6 +748,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
+ case V4L2_CID_TUNE_DEEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
@@ -745,6 +761,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FM_TX_CLASS:
case V4L2_CID_FLASH_CLASS:
case V4L2_CID_JPEG_CLASS:
+ case V4L2_CID_FM_RX_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index c9c9a46..f94acfd 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1137,6 +1137,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
#define V4L2_CTRL_CLASS_FLASH 0x009c /* Camera flash controls */
#define V4L2_CTRL_CLASS_JPEG 0x009d/* JPEG-compression
controls */
+#define V4L2_CTRL_CLASS_FM_RX 0x009e /* FM Receiver control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1782,6 +1783,13 @@ enum v4l2_jpeg_chroma_subsampling {
#defineV4L2_JPEG_ACTIVE_MARKER_DQT (1 17)
#defineV4L2_JPEG_ACTIVE_MARKER_DHT (1 18)
+/* FM Receiver class control IDs */
+#define V4L2_CID_FM_RX_CLASS_BASE (V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_RDS_AF_SWITCH (V4L2_CID_FM_RX_CLASS_BASE + 1)
+#define V4L2_CID_TUNE_DEEMPHASIS (V4L2_CID_FM_RX_CLASS_BASE + 2)
+
/*
* T U N I N G
*/
@@ -1849,7 +1857,8 @@ struct v4l2_hw_freq_seek {
__u32 seek_upward;
__u32 wrap_around;
__u32 spacing;
- __u32 reserved[7];
+ __u32 fm_band;
+ __u32 reserved[6];
};
/*
--
1.7.4.1
--
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
[PATCH V3 1/5] [Media] WL128x: Add support for FM TX RDS
From: Manjunatha Halli x0130...@ti.com
This patch adds support for following FM TX RDS features,
1. Radio Text
2. PS Name
3. PI Code
4. PTY Code.
Along with above this patch fixes few other minor issues(like
fm tx get frequency, unnecessary error messages etc).
Signed-off-by: Manjunatha Halli x0130...@ti.com
---
drivers/media/radio/wl128x/fmdrv_common.c | 17 +++---
drivers/media/radio/wl128x/fmdrv_common.h | 17 +++
drivers/media/radio/wl128x/fmdrv_rx.c |2 +-
drivers/media/radio/wl128x/fmdrv_tx.c | 41 ++---
drivers/media/radio/wl128x/fmdrv_tx.h |3 +-
drivers/media/radio/wl128x/fmdrv_v4l2.c | 47 +
6 files changed, 90 insertions(+), 37 deletions(-)
diff --git a/drivers/media/radio/wl128x/fmdrv_common.c
b/drivers/media/radio/wl128x/fmdrv_common.c
index bf867a6..fcce61a 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -354,7 +354,7 @@ static void send_tasklet(unsigned long arg)
/* Check, is there any timeout happened to last transmitted packet */
if ((jiffies - fmdev-last_tx_jiffies) FM_DRV_TX_TIMEOUT) {
- fmerr(TX timeout occurred\n);
+ fmdbg(TX timeout occurred\n);
atomic_set(fmdev-tx_cnt, 1);
}
@@ -615,7 +615,11 @@ static void fm_irq_handle_rds_start(struct fmdev *fmdev)
{
if (fmdev-irq_info.flag FM_RDS_EVENT fmdev-irq_info.mask) {
fmdbg(irq: rds threshold reached\n);
- fmdev-irq_info.stage = FM_RDS_SEND_RDS_GETCMD_IDX;
+ /* If RSSI reached below threshold then dont get RDS data */
+ if (fmdev-irq_info.flag FM_LEV_EVENT)
+ fmdev-irq_info.stage = FM_HW_TUNE_OP_ENDED_IDX;
+ else
+ fmdev-irq_info.stage = FM_RDS_SEND_RDS_GETCMD_IDX;
} else {
/* Continue next function in interrupt handler table */
fmdev-irq_info.stage = FM_HW_TUNE_OP_ENDED_IDX;
@@ -1129,8 +1133,9 @@ int fmc_set_freq(struct fmdev *fmdev, u32 freq_to_set)
int fmc_get_freq(struct fmdev *fmdev, u32 *cur_tuned_frq)
{
- if (fmdev-rx.freq == FM_UNDEFINED_FREQ) {
- fmerr(RX frequency is not set\n);
+ if (fmdev-rx.freq == FM_UNDEFINED_FREQ
+ fmdev-tx_data.tx_frq == FM_UNDEFINED_FREQ) {
+ fmerr(RX/TX frequency is not set\n);
return -EPERM;
}
if (cur_tuned_frq == NULL) {
@@ -1144,7 +1149,7 @@ int fmc_get_freq(struct fmdev *fmdev, u32 *cur_tuned_frq)
return 0;
case FM_MODE_TX:
- *cur_tuned_frq = 0; /* TODO : Change this later */
+ *cur_tuned_frq = fmdev-tx_data.tx_frq;
return 0;
default:
@@ -1574,6 +1579,8 @@ int fmc_prepare(struct fmdev *fmdev)
fmdev-rx.af_mode = FM_RX_RDS_AF_SWITCH_MODE_OFF;
fmdev-irq_info.retry = 0;
+ fmdev-tx_data.tx_frq = FM_UNDEFINED_FREQ;
+
fm_rx_reset_rds_cache(fmdev);
init_waitqueue_head(fmdev-rx.rds.read_queue);
diff --git a/drivers/media/radio/wl128x/fmdrv_common.h
b/drivers/media/radio/wl128x/fmdrv_common.h
index d9b9c6c..196ff7d 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.h
+++ b/drivers/media/radio/wl128x/fmdrv_common.h
@@ -48,8 +48,8 @@ struct fm_reg_table {
#define SEARCH_LVL_SET 15
#define BAND_SET 16
#define MUTE_STATUS_SET 17
-#define RDS_PAUSE_LVL_SET18
-#define RDS_PAUSE_DUR_SET19
+#define AUD_PAUSE_LVL_SET18
+#define AUD_PAUSE_DUR_SET19
#define RDS_MEM_SET 20
#define RDS_BLK_B_SET21
#define RDS_MSK_B_SET22
@@ -84,11 +84,12 @@ struct fm_reg_table {
#define FM_POWER_MODE254
#define FM_INTERRUPT 255
+#define STATION_VALID 123
/* Transmitter API */
#define CHANL_SET55
-#define CHANL_BW_SET 56
+#define SCAN_SPACING_SET 56
#define REF_SET 57
#define POWER_ENB_SET90
#define POWER_ATT_SET58
@@ -103,7 +104,8 @@ struct fm_reg_table {
#define MONO_SET 66
#define MUTE 92
#define MPX_LMT_ENABLE 67
-#define PI_SET 93
+#define REF_ERR_SET 93
+#define PI_SET 68
#define ECC_SET 69
#define PTY 70
#define AF 71
@@ -120,6 +122,10 @@ struct fm_reg_table {
#define TX_AUDIO_LEVEL_TEST 96
#define TX_AUDIO_LEVEL_TEST_THRESHOLD73
#define TX_AUDIO_INPUT_LEVEL_RANGE_SET 54
+#define TX_AUDIO_LEVEL_GET 7
+#define READ_FMANT_TUNE_VALUE104
+
+/* New FM APIs (Rx and Tx) */
#define RX_ANTENNA_SELECT87
#define I2C_DEV_ADDR_SET 86
#define REF_ERR_CALIB_PARAM_SET
Re: [RFC v3 1/2] v4l: Do not use enums in IOCTL structs
Hi Hans,
Em 02-05-2012 17:45, Hans Verkuil escreveu:
On Wed May 2 2012 21:13:47 Sakari Ailus wrote:
Replace enums in IOCTL structs by __u32. The size of enums is variable and
thus problematic. Compatibility structs having exactly the same as original
definition are provided for compatibility with old binaries with the
required conversion code.
Does someone actually have hard proof that there really is a problem? You
know,
demonstrate it with actual example code?
It's pretty horrible that you have to do all those conversions and that code
will be with us for years to come.
For most (if not all!) architectures sizeof(enum) == sizeof(u32), so there is
no need for any compat code for those.
Most is not enough. We need a solution for all.
Also, the usage of -fshort-enum compilation directive would cause a V4L2
application
to not work.
I've checked with a gcc developer: he said that,
C standard says that the type should be represented as an integer, but it does
allow
that it could be represented by a sorter type, like char. Gcc also allows using
larger
enumber types, as a compatible extension, but doesn't use (by default) sorter
types,
except if packed attribute is used.
As we use __packed on several structs, this can cause troubles.
It seems that the compiler may also choose to use either signed or unsigned
integers
for enums.
He also doesn't recommend to use enums for any bitfield, as this is not defined
on
C standard, and the way GCC implements it can cause troubles.
I would prefer a simpler solution, but, after thinking for some time, we should
really
do something like that. Yes, compat code sucks, but, on the long term, we'll
get rid
of all those mess. If we don't do that, I'm sure that this problem will return
back in
the future (as this is the second time it returned. If we had fixed it on that
time,
all our problems would already be solved nowadays).
Note that I don't question that using u32 is better than using enums, but I
really wonder if there is any need for all the conversions.
We can speed-up the conversions, with something like:
enum foo {
BAR
};
if (sizeof(foo) != sizeof(u32))
call_compat_logic().
I suspect that sizeof() won't work inside a macro.
Regards,
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
[PATCH] mt9v032: Correct the logic for the auto-exposure setting
The driver uses the ctrl value passed in as a bool to determine whether
to enable auto-exposure, but the auto-exposure setting is defined as an
enum where AUTO has a value of 0 and MANUAL has a value of 1. This leads
to a reversed logic where if you send in AUTO, it actually sets manual
exposure and vice-versa.
Signed-off-by: Kartik Mohta kartikmo...@gmail.com
---
drivers/media/video/mt9v032.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/mt9v032.c b/drivers/media/video/mt9v032.c
index 75e253a..8ea8737 100644
--- a/drivers/media/video/mt9v032.c
+++ b/drivers/media/video/mt9v032.c
@@ -470,6 +470,7 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
container_of(ctrl-handler, struct mt9v032, ctrls);
struct i2c_client *client = v4l2_get_subdevdata(mt9v032-subdev);
u16 data;
+ int aec_value;
switch (ctrl-id) {
case V4L2_CID_AUTOGAIN:
@@ -480,8 +481,13 @@ static int mt9v032_s_ctrl(struct v4l2_ctrl *ctrl)
return mt9v032_write(client, MT9V032_ANALOG_GAIN, ctrl-val);
case V4L2_CID_EXPOSURE_AUTO:
+ if(ctrl-val == V4L2_EXPOSURE_MANUAL)
+ aec_value = 0;
+ else
+ aec_value = 1;
+
return mt9v032_update_aec_agc(mt9v032, MT9V032_AEC_ENABLE,
- ctrl-val);
+ aec_value);
case V4L2_CID_EXPOSURE:
return mt9v032_write(client, MT9V032_TOTAL_SHUTTER_WIDTH,
--
1.7.10.1
--
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 v3 2/2] v4l: Implement compat functions for enum to __u32 change
Em 02-05-2012 16:13, Sakari Ailus escreveu:
Implement compat functions to provide conversion between structs containing
enums and those not. The functions are intended to be removed when the
support for such old binaries is no longer necessary.
This is not a full review of this patch, as checking the full logic
will consume some time.
This is just a few points to consider.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/Kconfig | 12 +
drivers/media/video/v4l2-ioctl.c | 684
+-
2 files changed, 687 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f2479c5..949f804 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -7,6 +7,18 @@ config VIDEO_V4L2
depends on VIDEO_DEV VIDEO_V4L2_COMMON
default VIDEO_DEV VIDEO_V4L2_COMMON
+config V4L2_COMPAT
+ bool Compatibility for old binaries
+ depends on VIDEO_V4L2
+ default y
+ ---help---
+ Compatibility code to support binaries compiled with old V4L2
+ IOCTL definitions containing enums that have been replaced by
+ __u32. If you do not need to use such binaries you can disable
+ this option.
+
+ When in doubt, say Y.
+
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index 5b2ec1f..9b88360 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2303,6 +2303,653 @@ static long __video_do_ioctl(struct file *file,
return ret;
}
+#ifdef CONFIG_V4L2_COMPAT
Hmm... maybe the better would be to put it on a separate file.
Also, as the size on userspace can be different than on Kernelspace, a similar
code is needed at v4l2-compat-ioctl32.c.
As I said before (not sure if it was via e-mail or on irc), I suspect that the
code there can be simplified a lot, as only the structs with enums and pointers
require compat code. For all others, the code could simply use the default
behavior.
+
+static inline unsigned int get_non_compat_cmd(unsigned int cmd)
+{
+ switch (cmd) {
+ case VIDIOC_ENUM_FMT_ENUM:
+ return VIDIOC_ENUM_FMT;
+ case VIDIOC_G_FMT_ENUM:
+ return VIDIOC_G_FMT;
+ case VIDIOC_S_FMT_ENUM:
+ return VIDIOC_S_FMT;
+ case VIDIOC_REQBUFS_ENUM:
+ return VIDIOC_REQBUFS;
+ case VIDIOC_QUERYBUF_ENUM:
+ return VIDIOC_QUERYBUF;
+ case VIDIOC_G_FBUF_ENUM:
+ return VIDIOC_G_FBUF;
+ case VIDIOC_S_FBUF_ENUM:
+ return VIDIOC_S_FBUF;
+ case VIDIOC_QBUF_ENUM:
+ return VIDIOC_QBUF;
+ case VIDIOC_DQBUF_ENUM:
+ return VIDIOC_DQBUF;
+ case VIDIOC_G_PARM_ENUM:
+ return VIDIOC_G_PARM;
+ case VIDIOC_S_PARM_ENUM:
+ return VIDIOC_S_PARM;
+ case VIDIOC_G_TUNER_ENUM:
+ return VIDIOC_G_TUNER;
+ case VIDIOC_S_TUNER_ENUM:
+ return VIDIOC_S_TUNER;
+ case VIDIOC_QUERYCTRL_ENUM:
+ return VIDIOC_QUERYCTRL;
+ case VIDIOC_G_FREQUENCY_ENUM:
+ return VIDIOC_G_FREQUENCY;
+ case VIDIOC_S_FREQUENCY_ENUM:
+ return VIDIOC_S_FREQUENCY;
+ case VIDIOC_CROPCAP_ENUM:
+ return VIDIOC_CROPCAP;
+ case VIDIOC_G_CROP_ENUM:
+ return VIDIOC_G_CROP;
+ case VIDIOC_S_CROP_ENUM:
+ return VIDIOC_S_CROP;
+ case VIDIOC_TRY_FMT_ENUM:
+ return VIDIOC_TRY_FMT;
+ case VIDIOC_G_SLICED_VBI_CAP_ENUM:
+ return VIDIOC_G_SLICED_VBI_CAP;
+ case VIDIOC_S_HW_FREQ_SEEK_ENUM:
+ return VIDIOC_S_HW_FREQ_SEEK;
+ case VIDIOC_CREATE_BUFS_ENUM:
+ return VIDIOC_CREATE_BUFS;
+ case VIDIOC_PREPARE_BUF_ENUM:
+ return VIDIOC_PREPARE_BUF;
+ default:
+ return cmd;
+ }
+}
+
+#define get_user_conv(x, ptr)\
+ ({ \
+ typeof (*ptr) tmp; \
+ int rval; \
+ \
+ rval = get_user(tmp, ptr); \
+ if (!rval) \
+ x = (typeof (x))tmp;\
+ \
+ rval; \
+ })
+
+static int get_user_pix_format(struct v4l2_pix_format *k,
+struct v4l2_pix_format_enum *u)
+{
+ return get_user(k-width, u-width)
+ || get_user(k-height, u-height)
+ || get_user(k-pixelformat, u-pixelformat)
+ || get_user_conv(k-field, u-field)
+ || get_user(k-bytesperline, u-bytesperline)
+ || get_user(k-sizeimage, u-sizeimage)
+ ||
Re: [RFC v3 2/2] v4l: Implement compat functions for enum to __u32 change
Hi Mauro,
On Wednesday 02 May 2012 19:32:23 Mauro Carvalho Chehab wrote:
Em 02-05-2012 16:13, Sakari Ailus escreveu:
Implement compat functions to provide conversion between structs
containing enums and those not. The functions are intended to be removed
when the support for such old binaries is no longer necessary.
This is not a full review of this patch, as checking the full logic
will consume some time.
This is just a few points to consider.
[snip]
-video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
+video_usercopy(struct file *file, unsigned int compat_cmd, unsigned long
arg,
v4l2_kioctl func)
{
charsbuf[128];
@@ -2401,6 +3048,7 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
size_t array_size = 0;
void __user *user_ptr = NULL;
void**kernel_ptr = NULL;
+ unsigned int cmd = get_non_compat_cmd(compat_cmd);
This will put a penalty on archs where sizeof(u32) == sizeof(enum), with
covers most of the cases.
My suggestion is to, instead, call it at the end of __video_do_ioctl, at
the default clause, with a recursive call to __video_do_ioctl().
Would that work for has_array_args ioctls ? video_usercopy() won't copy the
array. The compat code could possibly handle that though.
What about making get_non_compat_cmd() return its argument directly when
sizeof(__u32) == sizeof(enum) ? The performance impact should be negligible.
It should be noticed that UVC driver and pvrusb2 are the only two drivers
that don't use __video_do_ioctl(). So, a logic similar to it should be
implemented there.
/* Copy arguments into temp kernel buffer */
if (_IOC_DIR(cmd) != _IOC_NONE) {
@@ -2418,12 +3066,23 @@ video_usercopy(struct file *file, unsigned int
cmd, unsigned long arg,
if (_IOC_DIR(cmd) _IOC_WRITE) {
unsigned long n = cmd_input_size(cmd);
- if (copy_from_user(parg, (void __user *)arg, n))
- goto out;
-
- /* zero out anything we don't copy from userspace */
- if (n _IOC_SIZE(cmd))
- memset((u8 *)parg + n, 0, _IOC_SIZE(cmd) - n);
+ if (cmd == compat_cmd) {
+ if (copy_from_user(
+ parg, (void __user *)arg, n))
+ goto out;
+
+ /*
+* zero out anything we don't copy
+* from userspace
+*/
+ if (n _IOC_SIZE(cmd))
+ memset((u8 *)parg + n, 0,
+ _IOC_SIZE(cmd) - n);
+ } else {
+ if (copy_compat_from_user(compat_cmd, parg,
+ (void __user *)arg))
+ goto out;
+ }
} else {
/* read-only ioctl */
memset(parg, 0, _IOC_SIZE(cmd));
@@ -2471,8 +3130,15 @@ out_array_args:
switch (_IOC_DIR(cmd)) {
case _IOC_READ:
case (_IOC_WRITE | _IOC_READ):
- if (copy_to_user((void __user *)arg, parg, _IOC_SIZE(cmd)))
- err = -EFAULT;
+ if (cmd == compat_cmd) {
+ if (copy_to_user((void __user *)arg, parg,
+_IOC_SIZE(cmd)))
+ err = -EFAULT;
+ } else {
+ if (copy_compat_to_user(compat_cmd, (void __user *)arg,
+ parg))
+ err = -EFAULT;
+ }
break;
}
--
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
[PATCH] Add quirk for camera of Lenovo Thinkpad X220 Tablet
---
lib/libv4lconvert/control/libv4lcontrol.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/libv4lconvert/control/libv4lcontrol.c
b/lib/libv4lconvert/control/libv4lcontrol.c index e802a90..f9fda71 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -134,6 +134,8 @@ static const struct v4lcontrol_flags_info
v4lcontrol_flags[] = { FUJITSU, LIFEBOOK NH751 },
{ 0x04f2, 0xb217, 0, LENOVO, 42992QG,
V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED },
+ { 0x04f2, 0xb217, 0, LENOVO, 42982YG,
+ V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED },
{ 0x04f2, 0xb27c, 0, LENOVO, 12973MG,
V4LCONTROL_HFLIPPED | V4LCONTROL_VFLIPPED, 0, NULL, NULL,
NULL, ThinkPad Edge E325 },
--
1.7.10
--
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 v3 1/2] v4l: Do not use enums in IOCTL structs
On Wed, 2012-05-02 at 19:17 -0300, Mauro Carvalho Chehab wrote:
We can speed-up the conversions, with something like:
enum foo {
BAR
};
if (sizeof(foo) != sizeof(u32))
call_compat_logic().
I suspect that sizeof() won't work inside a macro.
sizeof() is evaluated at compile time, after preprocessing.
It should work inside of a macro.
See the ARRAY_SIZE() macro in include/linux/kernel.h for a well tested
example.
Regards,
Andy
--
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: HVR-1600 QAM recordings with slight glitches in them
On 12-04-29 08:09 PM, Devin Heitmueller wrote: I don't know why you're not seeing valid data on femon with the 950q. It should be printing out fine, and it's on the same 0.1 dB scale. Try running just azap and see if the SNR is reported there. $ azap -c ~/last-channel-scan.prev 100-3 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 65100 Hz video pid 0x, audio pid 0x07c1 status 00 | signal | snr | ber | unc | status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr 0190 | ber | unc | FE_HAS_LOCK status 1f | signal 0190 | snr | ber | unc | FE_HAS_LOCK status 1f | signal | snr 0190 | ber | unc | FE_HAS_LOCK ... Doesn't seem to be useful values. This indeed feels like a marginal signal condition problem, and Andy's assertion is well founded that the mxl5005/s5h1409 isn't exactly the best combo compared to more modern tuners and demodulators (Hauppauge switched to the tda18271 and s5h1411 for the newer revision of the HVR-1600). Well, now that the coax connector has come loose on the digital tuner (i.e. it spins albeit with enough friction that screwing a coax connector on and off is still quite doable but it would seem spins enough to have broken the connection internally and thus the tuner no longer receives signal) maybe it's time to cut my losses here and just consider this HVR-1600 garbage. I've wasted more than enough time on what's turned out to just be marginal hardware. ~sigh~ I wonder if I can still find the supported hardware rev. of the KWorld UB-435 around anywhere. The local computer store has one for $40 but they have no way of telling me if it's the new hardware rev. or the old one. Cheers, b. signature.asc Description: OpenPGP digital signature
