Re: mt9p031 on omap3530, no interrupts from ISP
Am 27.11.2011 19:32, schrieb Chris Whittenburg: I'm using the 3.0.8 kernel, with a few changes to add support for mt9p031 on a beagleboard xm. I'm configuring with: media-ctl -v -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v -f 'mt9p031 2-0048:0[SGRBG12 370x243], OMAP3 ISP CCDC:0[SGRBG12 370x243], OMAP3 ISP CCDC:1[SGRBG12 370x243]' and then running: yavta -f SGRBG12 -s 368x243 -n 4 --capture=10 --skip 3 -F `media-ctl -e OMAP3 ISP CCDC output` Which hangs trying to de-queue a buffer: root@beagleboard:~# yavta -f SGRBG12 -s 368x243 -n 4 --capture=10 --skip 3 -F `media-ctl -e OMAP3 ISP CCDC output` Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG12 (32314142) 368x243 buffer size 178848 Video format: SGRBG12 (32314142) 368x243 buffer size 178848 4 buffers requested. length: 178848 offset: 0 Buffer 0 mapped at address 0x4023d000. length: 178848 offset: 180224 Buffer 1 mapped at address 0x402b9000. length: 178848 offset: 360448 Buffer 2 mapped at address 0x4039e000. length: 178848 offset: 540672 Buffer 3 mapped at address 0x40435000. Communication is good with the mt9p031, and I can see pclk, and signals on the data lines, but I don't seem to be getting any interrupts from the ISP. Any pointers on what I should check? Do you have the cam_xclk always enabled? The isp only works if you set the cam_xclk to zero, when you don't use the camera. -- 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: Hauppauge HVR-900 HD
On 11/26/11 15:20, Andy Walls wrote: Fredrik Lingvallfredrik.lingv...@gmail.com wrote: On 11/25/11 23:14, Devin Heitmueller wrote: On Fri, Nov 25, 2011 at 3:54 PM, Fredrik Lingvall fredrik.lingv...@gmail.com wrote: Hi All, I have a Hauppauge HVR-900 HD with ID 2040:b138. Is this device supported, and if so, which driver and firmware do I need? Hi Frank, It's not currently supported under Linux as it uses a demodulator that there is currently no driver for. As far as I know, nobody's working on it. Regards, Devin Thanks for the info Devin. I had some hope since I found this page: http://forum.ubuntu-it.org/index.php/topic,423395.5/wap2.html The dmesg output at least shows much more than I have been able to get (I use 3.2.0-rc3 from the linuxtv git rep). They seem to be able to at least load firmware into the device. It's in Italian so I don't understand much of what they are discussing though. /Fredrik -- 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 On that page they seem to have the unit recognized and a configuration for the analog side of the unit. They also mention a Silabs SI2165 DVB-T/-C demodulator which is obviously not supported. Regards, Andy They had a link to the code on the page: http://misterox.altervista.org/cx231xx_drivers/newversion_cx231xx.tar.gz I did a (quick) comparison with that code and the code that's in 3.2.0-rc3. From what I could see it was not a quick fix to port it to 3.2.0-rc3. I will look at it a bit more to see if I can get analog to work too (with 3.2.0-rc3). /Fredrik -- 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 1/2] dma-buf: Introduce dma buffer sharing mechanismch
On Mon, Nov 28, 2011 at 08:47:31AM +0100, Marek Szyprowski wrote: On Tuesday, November 08, 2011 7:43 PM Daniel Vetter wrote: Thanks for the clarification. I think this is another reason why get_scatterlist should return the sg_list already mapped into the device address space - it's more consisten with the other dma apis. Another reason to completely hide everything but mapped addresses is crazy stuff like this mem --- tiling iommu -+- gpu | +- scanout engine | +- mpeg decoder where it doesn't really make sense to talk about the memory backing the dma buffer because that's smeared all over the place due to tiling. IIRC for the case of omap these devices can also access memory through other paths and iommut that don't tile (but just remap like a normal iommu) I really don't get why you want to force the exporter to map the buffer into clients dma address space. Only the client device might know all the quirks required to do this correctly. Exporter should only provide a scatter-list with the memory that belongs to the exported buffer (might be pinned). How do you want to solve the following case - the gpu hardware from your diagram and a simple usb webcam with generic driver. The application would like to export a buffer from the webcam to scanout engine. How the generic webcam driver might know HOW to set up the tiller to create correct mappings for the GPU/scanout? IMHO only a GPU driver is capable of doing that assuming it got just a scatter list from the webcam driver. You're correct that only the gpu knows how to put things into the tiler (and maybe other devices that have access to it). Let me expand my diagram so that you're webcam fits into the picture. mem -+- tiling iommu -+- gpu | | | +- scanout engine | | | +- mpeg decoder | | | | +- direct dma -+ | +- iommua A -+- usb hci | +- other devices | ... A few notes: - might not be exactly how omap really looks like - the devices behind tiler have different device address space windows to access the different paths to main memory. No other device can access the tiler, iirc. - your webcam doesn't exist on this because we can't dma from it's memory, we can only zero-copy from the memory the usb hci transferred the frame to. Now when when e.g. the scanout engine calls get_scatterlist you only call dma_map_sg (which does nothing, because there's no iommu that's managed by the core kernel code for it). The scanout engine will then complain that your stuff is not contiguous and bail out. Or it is indeed contiguous and things Just Work. The much more interesting case is when the mpeg decoder and the gpu share a buffer (think video on rotating cube or whatever other gui transition you fancy). Then the omap tiler code can check whether the the device sits behind the tiler (e.g. with some omap-specific device tree attribute) and hand out a linear view to a tiled buffer. In other words, whereever you're currently calling one of the map/unmap dma api variants, you would call get/put_scatterlist (or better the new name I'm proposing). So I also don't see your argument about only the client knows how to map something into address space. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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 query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
Hi Alex, On Sunday 27 November 2011 21:01:23 Alex wrote: Hi guys, I'm using kernel 3.2-rc3 and get following in dmesg on every try to use thinkpad integrated camera (here I did rmmod and modprobe before test): [ 9481.258170] usbcore: deregistering interface driver uvcvideo [ 9481.296659] uvcvideo: Failed to submit URB 0 (-28). [ 9481.296677] uvcvideo 1-1.6:1.1: resume error -28 [ 9490.117546] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b221) [ 9490.119166] input: Integrated Camera as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input13 [ 9490.119298] usbcore: registered new interface driver uvcvideo [ 9490.119302] USB Video Class driver (1.1.1) [ 9498.101683] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 9498.113603] uvcvideo: Failed to submit URB 0 (-28). Those two errors might be unrelated. For the second one, I'm tempted to blame http://git.kernel.org/?p=linux/kernel/git/stable/linux- stable.git;a=commit;h=f0cc710a6dec5b808a6f13f1f8853c094fce5f12. Could you please try reverting it, and see if it fixes your issue ? If so, let's report that to the linux-usb mailing list. For the first one, could you please send me the lsusb -v output for your webcam ? -- 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: Problem with linux-3.1.3
Hi Hendrik, On Sunday 27 November 2011 14:04:02 Hendrik Sattler wrote: Hi, I just updated by self-built kernel-from v3.1 to v3.1.3. With the new version, my built-in webcam[1] does not work anymore but it did with v3.1. $ luvcview luvcview 0.2.6 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: Frame format: MJPG Frame size: 640x480 Frame rate: 30 fps libv4l2: error turning on stream: No space left on device Unable to start capture: No space left on device Error grabbing Cleanup done. Exiting ... The following kernel message pop up with those tries: uvcvideo: UVC non compliance - GET_MIN/MAX(PROBE) incorrectly supported. Enabling workaround. That can usually be safely ignored. Let's try to fix the second issue first. uvcvideo: Failed to submit URB 0 (-28). Same for using e.g. Google+ Hangouts which worked fine using v3.1. Any ideas what might be wrong? I'm tempted to blame http://git.kernel.org/?p=linux/kernel/git/stable/linux- stable.git;a=commit;h=f0cc710a6dec5b808a6f13f1f8853c094fce5f12. Could you please try reverting that patch and see if it fixes your issue ? -- 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] SUBDEV_S/G_SELECTION IOCTLs
Hi Sakari, On Saturday 26 November 2011 10:25:19 Sakari Ailus wrote: Laurent Pinchart wrote: On Thursday 10 November 2011 23:29:34 Sakari Ailus wrote: On Thu, Nov 10, 2011 at 04:23:19PM +0100, Tomasz Stanislawski wrote: On 11/08/2011 10:55 PM, Sakari Ailus wrote: [snip] A sensor The intent is to obtain a VGA image from a 8 MP sensor which provides following pipeline: pixel_array:0 [crop] --- 0:binner:1 --- [crop] 0:scaler:1 [crop] Binner is an entity which can perform scaling, but only in factor of 1/n, where n is a positive integer. No cropping is needed. The intent is to get a 640x480 image from such sensor. (This doesn't involve any other configuration as the image size related one.) The initial state of the pipeline pixel_array:0 binner:0binner:1scaler:0scaler:1 compose (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/ 3 600x2464 crop (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/3600x2464 ( 0 ,0)/3600x2464 fmt 3600x2464 3600x2464 3600x2464 3600x2464 3600x2464 This will configure the binning on the binner subdev sink pad: SUBDEV_S_SELECTION(binner:0, COMPOSE_ACTIVE, (0,0)/1800x1232); pixel_array:0 binner:0binner:1scaler:0scaler:1 compose (0,0)/3600x2464 (0,0)/1800x1232 (0,0)/1800x1232 (0,0)/3600x2464 (0,0)/ 3 600x2464 crop (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/1800x1232 (0,0)/3600x2464 ( 0 ,0)/3600x2464 fmt 3600x2464 3600x2464 1800x1232 3600x2464 3600x2464 The same format must be set on the scaler pad 0 as well. This will reset the size inside the scaler to a sane default, which is no scaling: SUBDEV_S_FMT(scaler:0, 1800x1232); pixel_array:0 binner:0binner:1scaler:0scaler:1 compose (0,0)/3600x2464 (0,0)/1800x1232 (0,0)/1800x1232 (0,0)/1800x1232 (0,0)/ 1 800x1232 crop (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/1800x1232 (0,0)/1800x1232 ( 0 ,0)/1800x1232 fmt 3600x2464 3600x2464 1800x1232 1800x1232 1800x1232 I assume that scaler can upscale image 1800x1232 on scaler:0 to 3600x2464 on pad scaler:1. Therefore the format and compose targets on scaler:1 should not be changed. Open question one: do we need a flag for other than s_selection to not to reset the following stages? That said, we also need to define a behaviour for that: if changes must be made e.g. to crop and compose rectangle on both sink and source pads, then how are they made? Shouldn't that be left to the drivers to decide ? Different devices will likely have different requirements. That's quite possible, but still there should be a general rule that should be obeyed if possible, or if it makes sense; hopefully both. I think that enabling the keep-pipeline bit should tell that the changes should be propagated as little as possible while not making too smart decisions. The expected behaviour should be defined. Shouldn't the keep-pipeline bit prevent any propagation ? Say, if one has configured crop and scaling on the sink pad, how does the change of the sink pad format affect the two? How about this: as the sink format still consists of the whole image, the crop rectangle should be scaled (by the driver) to fit to the new image and the scaling factor should be adjusted so that result after scaling in the sink pad changes as little as possible. There still may be changes to the image size after scaling depending on the properties of the hardware. Do you think that would that make sense? I think we should make it simpler. What about just setting all rectangles downstream to the same size as the sink format ? That's if the keep-pipeline bit isn't set, if it's set modifying the sink format should probably be disallowed. To perform further scaling on the scaler, the COMPOSE target is used on the scaler subdev's SOURCE pad: SUBDEV_S_SELECTION(scaler:0, COMPOSE_ACTIVE, (0,0)/640x480); pixel_array:0 binner:0binner:1scaler:0scaler:1 compose (0,0)/3600x2464 (0,0)/1800x1232 (0,0)/1800x1232 (0,0)/640x480 (0,0)/640 x480 crop (0,0)/3600x2464 (0,0)/3600x2464 (0,0)/1800x1232 (0,0)/1800x1232 ( 0 ,0)/640x480 fmt3600x2464 3600x2464 1800x1232 1800x1232 640x480 It is possible to compose 640x480 image into 1800x1232 data stream produced on scaler:1. Therefore the format on scaler:1 should not be changed. The area outside 640x480 would left undefined or filled by some pattern configured using controls. This situation was the reason of introducing PADDED target. Consider the same example but scaling factor larger than 1. Should there be cropping or should the compose rectangle be changed? Would it make sense to
Re: Using MT9P031 digital sensor
Hi Gary, On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: On 2011-11-11 07:26, Laurent Pinchart wrote: On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: On 2011-11-09 09:18, Laurent Pinchart wrote: On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: On 2011-11-08 17:54, Laurent Pinchart wrote: On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address
Re: [PATCH v2 1/2] v4l: Add new alpha component control
Hi Sylwester, On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: This control is intended for the video capture or memory-to-memory devices that are capable of setting up a per-pixel alpha component to some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to set the alpha component for all pixels to a value in range from 0 to 255. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml| 7 - drivers/media/video/v4l2-ctrls.c |7 + include/linux/videodev2.h |6 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..0adda43 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,17 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.3/title + orderedlist +listitem + paraAdded constantV4L2_CID_ALPHA_COMPONENT/constant control + to the link linkend=controlUser controls class/link. + /para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..4fd83c0 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -324,12 +324,6 @@ minimum value disables backlight compensation./entry (usually a microscope)./entry /row row - entryconstantV4L2_CID_LASTP1/constant/entry - entry/entry - entryEnd of the predefined control IDs (currently -constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry - /row - row entryconstantV4L2_CID_MIN_BUFFERS_FOR_CAPTURE/constant/entry entryinteger/entry entryThis is a read-only control that can be read by the application @@ -345,6 +339,25 @@ and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS. The value is the minimum number of OUTPUT buffers that is necessary for hardware to work./entry /row + row id=v4l2-alpha-component + entryconstantV4L2_CID_ALPHA_COMPONENT/constant/entry + entryinteger/entry + entry Sets the alpha color component on the capture device or on + the capture buffer queue of a mem-to-mem device. When a mem-to-mem + device produces frame format that includes an alpha component + (e.g. link linkend=rgb-formatspacked RGB image formats/link) + and the alpha value is not defined by the mem-to-mem input data + this control lets you select the alpha component value of all + pixels. It is applicable to any pixel format that contains an alpha + component. + /entry + /row + row + entryconstantV4L2_CID_LASTP1/constant/entry + entry/entry + entryEnd of the predefined control IDs (currently + constantV4L2_CID_ALPHA_COMPONENT/constant + 1)./entry + /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry entry/entry diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 4db272b..c13278b 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -428,8 +428,11 @@ colorspace constantV4L2_COLORSPACE_SRGB/constant./para paraBit 7 is the most significant bit. The value of a = alpha bits is undefined when reading from the driver, ignored when writing to the driver, except when alpha blending has been negotiated for a -link linkend=overlayVideo Overlay/link or link -linkend=osdVideo Output Overlay/link./para +link linkend=overlayVideo Overlay/link or link linkend=osd +Video Output Overlay/link or when alpha component has been configured +for a link linkend=captureVideo Capture/link by means of link +linkend=v4l2-alpha-component constantV4L2_CID_ALPHA_COMPONENT +/constant /link control./para example titleconstantV4L2_PIX_FMT_BGR24/constant 4 times; 4 pixel diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 5552f81..882cc84 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -466,6 +466,7 @@ const char
Re: [PATCH v3 1/3] fbdev: Add FOURCC-based format configuration API
Hi Florian,
On Friday 25 November 2011 23:09:40 Florian Tobias Schandinat wrote:
On 11/24/2011 10:50 AM, Laurent Pinchart wrote:
Hi Florian,
Gentle ping ?
Sorry, but I'm very busy at the moment and therefore time-consuming things,
like solving challenging problems, are delayed for some time.
No worries.
On Sunday 20 November 2011 11:55:22 Laurent Pinchart wrote:
On Sunday 20 November 2011 03:00:33 Florian Tobias Schandinat wrote:
Hi Laurent,
On 08/31/2011 11:18 AM, Laurent Pinchart wrote:
This API will be used to support YUV frame buffer formats in a
standard way.
looks like the union is causing problems. With this patch applied I get
errors like this:
CC [M] drivers/auxdisplay/cfag12864bfb.o
drivers/auxdisplay/cfag12864bfb.c:57: error: unknown field ‘red’
specified in initializer
*ouch*
gcc 4.6 chokes on anonymous unions initializers :-/
[snip]
@@ -246,12 +251,23 @@ struct fb_var_screeninfo {
__u32 yoffset; /* resolution
*/
__u32 bits_per_pixel; /* guess what
*/
-__u32 grayscale;/* != 0 Graylevels instead of
colors */
-struct fb_bitfield red; /* bitfield in fb mem if true
color, */
-struct fb_bitfield green; /* else only length is
significant */
-struct fb_bitfield blue;
-struct fb_bitfield transp; /* transparency
*/
+union {
+struct {/* Legacy format API
*/
+__u32 grayscale; /* 0 = color, 1 = grayscale
*/
+/* bitfields in fb mem if true color, else only
*/
+/* length is significant
*/
+struct fb_bitfield red;
+struct fb_bitfield green;
+struct fb_bitfield blue;
+struct fb_bitfield transp; /* transparency
*/
+};
+struct {/* FOURCC-based format API
*/
+__u32 fourcc; /* FOURCC format
*/
+__u32 colorspace;
+__u32 reserved[11];
+} fourcc;
+};
We can't name the union, otherwise this will change the userspace API.
We could fix the problem on the kernel side with
#ifdef __KERNEL__
} color;
#else
};
#endif
(and the structure that contains the grayscale, red, green, blue and
transp fields would need to be similarly named, the rgb name comes to
mind)
Which, I guess, would require modifying all drivers?
Unfortunately. That can be automated using coccinelle (I wrote a semantic
patch for that), but it will still be around 10k lines of diff.
I don't consider that a good idea. Maybe the simplest solution would be to
drop the union idea and just accept an utterly misleading name grayscale
for setting the FOURCC value.
I'll see if we can add an accessor macro to make it more explicit.
The colorspace could use one of the reserved fields at the end or do you
worry that we need to add a lot of other things?
For FOURCC-based format configuration I don't think we will need much more. If
we do need lots of additional fields in the future we might have to consider
an fbdev2 API ;-)
I'll resubmit patches based on this.
--
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] 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
---
drivers/media/video/omap3isp/ispvideo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index d100072..ffe7ce9 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const struct
v4l2_pix_format *pix,
mbus-width = pix-width;
mbus-height = pix-height;
- for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected if no
+* match is found.
+*/
+ for (i = 0; i ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus-code = formats[i].code;
mbus-colorspace = pix-colorspace;
mbus-field = pix-field;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: This control is intended for the video capture or memory-to-memory devices that are capable of setting up a per-pixel alpha component to some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to set the alpha component for all pixels to a value in range from 0 to 255. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml| 7 - drivers/media/video/v4l2-ctrls.c |7 + include/linux/videodev2.h |6 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..0adda43 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,17 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.3/title + orderedlist +listitem + paraAdded constantV4L2_CID_ALPHA_COMPONENT/constant control + to the link linkend=controlUser controls class/link. + /para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..4fd83c0 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -324,12 +324,6 @@ minimum value disables backlight compensation./entry (usually a microscope)./entry /row row - entryconstantV4L2_CID_LASTP1/constant/entry - entry/entry - entryEnd of the predefined control IDs (currently -constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry - /row - row entryconstantV4L2_CID_MIN_BUFFERS_FOR_CAPTURE/constant/entry entryinteger/entry entryThis is a read-only control that can be read by the application @@ -345,6 +339,25 @@ and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS. The value is the minimum number of OUTPUT buffers that is necessary for hardware to work./entry /row + row id=v4l2-alpha-component + entryconstantV4L2_CID_ALPHA_COMPONENT/constant/entry + entryinteger/entry + entry Sets the alpha color component on the capture device or on + the capture buffer queue of a mem-to-mem device. When a mem-to-mem + device produces frame format that includes an alpha component + (e.g. link linkend=rgb-formatspacked RGB image formats/link) + and the alpha value is not defined by the mem-to-mem input data + this control lets you select the alpha component value of all + pixels. It is applicable to any pixel format that contains an alpha + component. + /entry + /row + row + entryconstantV4L2_CID_LASTP1/constant/entry + entry/entry + entryEnd of the predefined control IDs (currently + constantV4L2_CID_ALPHA_COMPONENT/constant + 1)./entry + /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry entry/entry diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 4db272b..c13278b 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -428,8 +428,11 @@ colorspace constantV4L2_COLORSPACE_SRGB/constant./para paraBit 7 is the most significant bit. The value of a = alpha bits is undefined when reading from the driver, ignored when writing to the driver, except when alpha blending has been negotiated for a -link linkend=overlayVideo Overlay/link or link -linkend=osdVideo Output Overlay/link./para +link linkend=overlayVideo Overlay/link or link linkend=osd +Video Output Overlay/link or when alpha component has been configured +for a link linkend=captureVideo Capture/link by means of link +linkend=v4l2-alpha-component constantV4L2_CID_ALPHA_COMPONENT +/constant /link control./para example titleconstantV4L2_PIX_FMT_BGR24/constant 4 times; 4 pixel diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 5552f81..882cc84 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id) case V4L2_CID_ILLUMINATORS_2: return
Re: [PATCH v2 1/2] v4l: Add new alpha component control
On 11/28/2011 12:38 PM, Hans Verkuil wrote: On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: This control is intended for the video capture or memory-to-memory devices that are capable of setting up a per-pixel alpha component to some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to set the alpha component for all pixels to a value in range from 0 to 255. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml| 7 - drivers/media/video/v4l2-ctrls.c |7 + include/linux/videodev2.h |6 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) ... /* MPEG controls */ /* Keep the order of the 'case's the same as in videodev2.h! */ @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, /* Max is calculated as RGB888 that is 2^24 */ *max = 0xFF; break; +case V4L2_CID_ALPHA_COMPONENT: +*type = V4L2_CTRL_TYPE_INTEGER; +*step = 1; +*min = 0; +*max = 0xff; +break; Hmm. Do we really want to fix the max value to 0xff? The bits assigned to the alpha component will vary between 1 (V4L2_PIX_FMT_RGB555X), 4 (V4L2_PIX_FMT_RGB444) or 8 (V4L2_PIX_FMT_RGB32). It wouldn't surprise me to see larger sizes as well in the future (e.g. 16 bits). I think the max value should be the largest alpha value the hardware can support. The application has to set it to the right value that corresponds to the currently chosen pixel format. The driver just copies the first N bits into the alpha value where N depends on the pixel format. what do you think? Yes, ideally the maximum value of the alpha control should be changing depending on the set colour format. Currently the maximum value of the control equals maximum alpha value for the fourcc of maximum colour depth (V4L2_PIX_FMT_RGB32). What I found missing was a method for changing the control range dynamically, without deleting and re-initializing the control handler. If we reinitalize whole control handler the previously set control values are lost. And, AFAIU, single control cannot be currently removed and re-added to the control handler. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] s5p-fimc: Add support for alpha component configuration
On 11/28/2011 12:42 PM, Hans Verkuil wrote: On Friday 25 November 2011 16:39:32 Sylwester Nawrocki wrote: On Exynos SoCs the FIMC IP allows to configure globally the alpha component of all pixels for V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB555 and V4L2_PIX_FMT_RGB444 image formats. This patch adds a v4l2 control in order to let the applications control the alpha component value. The alpha value range depends on the pixel format, for RGB32 it's 0..255 (8-bits), for RGB555 - 0..1 (1-bit) and for RGB444 - 0..15 (4-bits). The v4l2 control range is always 0..255 and the alpha component data width is determined by currently set format on the V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE buffer queue. The applications need to match the alpha channel data width and the pixel format since the driver will ignore the alpha component bits that are not applicable to the configured pixel format. Will the driver ignore the least significant bits or the most significant bits? Most significant bits will be ignored, i.e. depending on fourcc the valid alpha bits are: V4L2_PIX_FMT_RGB555 - [0] V4L2_PIX_FMT_RGB444 - [3:0] V4L2_PIX_FMT_RGB32 - [7:0] -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] JPEG encoders control class
On Saturday 12 November 2011 20:46:25 Sylwester Nawrocki wrote:
Hi all,
This RFC is discussing the current support of JPEG encoders in V4L2 and
a proposal of new JPEG control class.
Motivation
==
JPEG encoder control is also required at the sub-device level, but
currently there are only defined ioctls in regular V4L2 device API. It
doesn't seem to make sense for these current ioctls to be inherited by
sub-device nodes, since they're not generic enough, incomplete and rather
not compliant with JFIF JPEG standard [2], [3].
Current implementation
==
Currently two ioctls are available [4]:
#define VIDIOC_G_JPEGCOMP _IOR('V', 61, struct v4l2_jpegcompression)
#define VIDIOC_S_JPEGCOMP _IOW('V', 62, struct v4l2_jpegcompression)
And the corresponding data structure is defined as:
struct v4l2_jpegcompression {
int quality;
int APPn; /* Number of APP segment to be written,
* must be 0..15 */
int APP_len; /* Length of data in JPEG APPn segment */
char APP_data[60]; /* Data in the JPEG APPn segment. */
int COM_len; /* Length of data in JPEG COM segment */
char COM_data[60]; /* Data in JPEG COM segment */
__u32 jpeg_markers; /* Which markers should go into the JPEG
* output. Unless you exactly know what
* you do, leave them untouched.
* Inluding less markers will make the
* resulting code smaller, but there will
* be fewer applications which can read it.
* The presence of the APP and COM marker
* is influenced by APP_len and COM_len
* ONLY, not by this property! */
#define V4L2_JPEG_MARKER_DHT (13)/* Define Huffman Tables */
#define V4L2_JPEG_MARKER_DQT (14)/* Define Quantization Tables */
#define V4L2_JPEG_MARKER_DRI (15)/* Define Restart Interval */
#define V4L2_JPEG_MARKER_COM (16)/* Comment segment */
#define V4L2_JPEG_MARKER_APP (17)/* App segment, driver will
* allways use APP0 */
};
What are the issues with such an implementation ?
These ioctls don't allow to re-program the quantization and Huffman tables
(DQT, DHT). Additionally, the standard valid segment length for the
application defined APPn and the comment COM segment is 2...65535, while
currently this is limited to 60 bytes.
Therefore APP_data and COM_data, rather than fixed size arrays, should be
pointers to a variable length buffer.
Only two drivers upstream really use VIDIOC_[S/G]_JPEGCOMP ioctls for
anything more than compression quality query/control. It might make sense
to create separate control for image quality and to obsolete the
v4l2_jpegcompressin::quality field.
Below is a brief review of usage of VIDIOC_[S/G]_JPEGCOMP ioctls in current
mainline drivers. Listed are parts of struct v4l2_jpegcompression used in
each case.
cpia2
-
vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality ignored, returns fixed value (80)
- uses APP_data/len, COM_data/len
- markers (only DHT can be disabled by the applications)
zoran
-
vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality, values 5...100, used only to calculate buffer size
- APP_data/len, COM_data/len
- markers field used to control inclusion of selected JPEG markers
in the output buffer
et61x251, sn9c102, s2255drv.c
-
Note that et61x251 and sn9c102 are going to be deprecated and removed at some
time in the future (gspca will support these devices).
vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality only,
valid values: et61x251, sn9c102use - {0, 1}, s2255drv.c - (0..100)
staging/media/go7007
vidioc_g_jpegcomp
- only for reporting JPEG markers (_DHT and _DQT returned),
- always returns fixed value of compression quality (50)
vidioc_s_jpegcomp
- does nothing, only returns error code when passed parameter
do not match the device capabilities
drivers/media/video/gspca/conex.c
drivers/media/video/gspca/jeilinj.c
drivers/media/video/gspca/mars.c
drivers/media/video/gspca/ov519.c
drivers/media/video/gspca/spca500.c
drivers/media/video/gspca/stk014.c
drivers/media/video/gspca/sunplus.c
drivers/media/video/gspca/topro.c
drivers/media/video/gspca/zc3xx.c
vidioc_s_jpegcomp
- compression quality
vidioc_g_jpegcomp
- compression quality, marker flags
drivers/media/video/gspca/sonixj.c
vidioc_g_jpegcomp
- compression quality, marker flags
--
The following is an initial draft of the
Re: uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
Hi Laurent, Unfortunately my laptop died today, I'll sent details once I repair it. Thanks, Alex On 28.11.2011 13:35, Laurent Pinchart wrote: Hi Alex, On Sunday 27 November 2011 21:01:23 Alex wrote: Hi guys, I'm using kernel 3.2-rc3 and get following in dmesg on every try to use thinkpad integrated camera (here I did rmmod and modprobe before test): [ 9481.258170] usbcore: deregistering interface driver uvcvideo [ 9481.296659] uvcvideo: Failed to submit URB 0 (-28). [ 9481.296677] uvcvideo 1-1.6:1.1: resume error -28 [ 9490.117546] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b221) [ 9490.119166] input: Integrated Camera as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input13 [ 9490.119298] usbcore: registered new interface driver uvcvideo [ 9490.119302] USB Video Class driver (1.1.1) [ 9498.101683] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 9498.113603] uvcvideo: Failed to submit URB 0 (-28). Those two errors might be unrelated. For the second one, I'm tempted to blame http://git.kernel.org/?p=linux/kernel/git/stable/linux- stable.git;a=commit;h=f0cc710a6dec5b808a6f13f1f8853c094fce5f12. Could you please try reverting it, and see if it fixes your issue ? If so, let's report that to the linux-usb mailing list. For the first one, could you please send me the lsusb -v output for your webcam ? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: On 11/28/2011 12:38 PM, Hans Verkuil wrote: On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: This control is intended for the video capture or memory-to-memory devices that are capable of setting up a per-pixel alpha component to some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to set the alpha component for all pixels to a value in range from 0 to 255. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml| 7 - drivers/media/video/v4l2-ctrls.c |7 + include/linux/videodev2.h |6 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) ... /* MPEG controls */ /* Keep the order of the 'case's the same as in videodev2.h! */ @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, /* Max is calculated as RGB888 that is 2^24 */ *max = 0xFF; break; + case V4L2_CID_ALPHA_COMPONENT: + *type = V4L2_CTRL_TYPE_INTEGER; + *step = 1; + *min = 0; + *max = 0xff; + break; Hmm. Do we really want to fix the max value to 0xff? The bits assigned to the alpha component will vary between 1 (V4L2_PIX_FMT_RGB555X), 4 (V4L2_PIX_FMT_RGB444) or 8 (V4L2_PIX_FMT_RGB32). It wouldn't surprise me to see larger sizes as well in the future (e.g. 16 bits). I think the max value should be the largest alpha value the hardware can support. The application has to set it to the right value that corresponds to the currently chosen pixel format. The driver just copies the first N bits into the alpha value where N depends on the pixel format. what do you think? Yes, ideally the maximum value of the alpha control should be changing depending on the set colour format. Currently the maximum value of the control equals maximum alpha value for the fourcc of maximum colour depth (V4L2_PIX_FMT_RGB32). What I found missing was a method for changing the control range dynamically, without deleting and re-initializing the control handler. If we reinitalize whole control handler the previously set control values are lost. You can just change the maximum field of struct v4l2_ctrl on the fly like this: struct v4l2_ctrl *my_ctrl; v4l2_ctrl_lock(my_ctrl); my_ctrl-maximum = 10; if (my_ctrl-cur.val my_ctrl-maximum) my_ctrl-cur.val = my_ctrl-maximum; v4l2_ctrl_unlock(my_ctrl); Although this might warrant a v4l2_ctrl_update_range() function that does this for you. Because after a change like this a V4L2_EVENT_CTRL should also be sent. In any case, this functionality isn't hard to add. Just let me know if you need it and I can make a patch for this. Regards, Hans And, AFAIU, single control cannot be currently removed and re-added to the control handler. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2011-11-28 04:07, Laurent Pinchart wrote: Hi Gary, On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: On 2011-11-11 07:26, Laurent Pinchart wrote: On Wednesday 09 November 2011 17:24:26 Gary Thomas wrote: On 2011-11-09 09:18, Laurent Pinchart wrote: On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote: On 2011-11-08 17:54, Laurent Pinchart wrote: On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote: On 2011-11-08 06:06, Laurent Pinchart wrote: On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote: On 2011-11-08 05:30, Javier Martinez Canillas wrote: On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote: On 2011-11-04 04:37, Laurent Pinchart wrote: On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote: I'm trying to use the MT9P031 digital sensor with the Media Controller Framework. media-ctl tells me that the sensor is set to capture using SGRBG12 2592x1944 Questions: * What pixel format in ffmpeg does this correspond to? I don't know if ffmpeg supports Bayer formats. The corresponding fourcc in V4L2 is BA12. ffmpeg doesn't seem to support these formats If your sensor is hooked up to the OMAP3 ISP, you can then configure the pipeline to include the preview engine and the resizer, and capture YUV data at the resizer output. I am using the OMAP3 ISP, but it's a bit unclear to me how to set up the pipeline Hi Gary, I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can help you. using media-ctl (I looked for documentation on this tool, but came up dry - is there any?) Do you have an example of how to configure this using the OMAP3 ISP? This is how I configure the pipeline to connect the CCDC with the Previewer and Resizer: ./media-ctl -l 'mt9v032 3-005c:0-OMAP3 ISP CCDC:0[1]' ./media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' ./media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' ./media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9v032 3-005c:0[SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 752x480]' ./media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 752x479]' ./media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 734x471]' ./media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 640x480]' Hope it helps, Thanks, I'll give this a try. I assume that your sensor is probably larger than 752x480 (the mt9p031 is 2592x1944 raw) and that setting the smaller frame size enables some scaling and/or cropping in the driver? The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should modify the resolutions in the above commands according to your sensor. Note that the CCDC crops online line when outputting data to the preview engine, and that the preview engine crops 18 columsn and 8 lines. You can then scale the image by modifying the resizer output size. Thanks. After much trial and error (and some kernel printks to understand what parameters were failing), I came up with this sequence: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG12 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' When I tried to grab though, I got this: # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6 Device /dev/video6 opened. Device `OMAP3 ISP resizer output' on `media' is a video capture device. Video format set: YUYV (56595559) 642x483 buffer size 633696 Video format: YUYV (56595559) 642x483 buffer size 633696 8 buffers requested. length: 633696 offset: 0 Buffer 0 mapped at address 0x4028c000. length: 633696 offset: 634880 Buffer 1 mapped at address 0x403d. length: 633696 offset: 1269760 Buffer 2 mapped at address 0x404b3000. length: 633696 offset: 1904640 Buffer 3 mapped at address 0x4062b000. length: 633696 offset: 2539520 Buffer 4 mapped at address 0x406d6000. length: 633696 offset: 3174400 Buffer 5 mapped at address 0x40821000. length: 633696 offset: 3809280 Buffer 6 mapped at address 0x4097c000. length: 633696 offset: 160 Buffer 7 mapped at address 0x40adf000. Unable to handle kernel NULL pointer dereference at virtual address 0018 Ouch :-( Could you please verify that arch/arm/mach-omap2/board-overo.c includes the following code, and that CONFIG_OMAP_MUX is enabled ? I'm
Re: Using MT9P031 digital sensor
Hi Gary, On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? -- 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] JPEG encoders control class
On 11/28/2011 01:20 PM, Hans Verkuil wrote: On Saturday 12 November 2011 20:46:25 Sylwester Nawrocki wrote: Hi all, This RFC is discussing the current support of JPEG encoders in V4L2 and a proposal of new JPEG control class. ... et61x251, sn9c102, s2255drv.c - Note that et61x251 and sn9c102 are going to be deprecated and removed at some time in the future (gspca will support these devices). Ok, thanks for the update. ... The following is an initial draft of the new control class o V4L2_CTRL_CLASS_JPEG As not everything might be covered by the controls (the application data and comment segments, quantization and Huffman tables, etc.) the control class should probably just complement VIDIOC_[G/S]_JPEGCOMP ioctls, rather than entirely replacing them. Proposed controls = 1. Chroma sub-sampling - The subsampling factors describe how each component of an input image is sampled, in respect to maximum sample rate in each spatial dimension. More general description can be found in [2], clause A.1.1., Dimensions and sampling factors. The chroma subsampling would describe how Cb, Cr components should be downsampled after coverting an input image from RGB to Y'CbCr color space. o V4L2_CID_JPEG_CHROMA_SUBSAMPLING - V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY - only luminance component is present, - V4L2_JPEG_CHROMA_SUBSAMPLING_410 - subsample Cr, Cb signals horizontally by 4 and vertically by 2 - V4L2_JPEG_CHROMA_SUBSAMPLING_411 - horizontally subsample Cr, Cb signals by a factor of 4 - V4L2_JPEG_CHROMA_SUBSAMPLING_420 - subsample Cr, Cb signals horizontally and vertically by 2 - V4L2_JPEG_CHROMA_SUBSAMPLING_422 - horizontally subsample Cr, Cb signals by a factor of 2, - V4L2_JPEG_CHROMA_SUBSAMPLING_444 - no chroma subsampling, each pixel has Y, Cr and Cb values. Using no subsampling produces sharper colours, even with higher compression (in order to achieve similar file size) [7], thus it seems important to provide the user with a method of precise subsampling control. 2. Restart interval (DRI) --- o V4L2_CID_JPEG_RESTART_INTERVAL The restart interval (DRI marker) determines the interval of inserting RSTm markers. The purpose of RSTm markers is to additionally reinitialize decoder process' predictor with initial default value. For lossy compression processes the restart interval is expressed in MCU (Minimm Coded Unit). If restart interval value is 0 DRI and RSTm (m = 0..7) markers will not be inserted. Consequently this control would make current V4L2_JPEG_MARKER_DRI markers flag redundant. This control would be useful for S5P JPEG IP block [6]. 3. Image quality o V4L2_CID_JPEG_QUALITY Image quality is not defined in the standard but it is used as an intermediate parameter by many encoders to control set of encoding parameters, which then allow to obtain certain image quality and corresponding file size. IMHO it makes sense to add the quality control to the JPEG class as it's widely used, not only for webcams. As far as the value range is concerned, probably it's better to leave this driver specific. The applications would then be more aware of what is supported by a device (min, max, step) and they could translate driver specific range into standardised values (0..100) if needed. Still the drivers could do the translation themselves if required. The specification would only say the 0..100 range is recommended. It should also say that higher numbers must represent better quality. ok, certainly it's a good idea to state it explicitly. I seem to have forgotten to write it down. 4. JPEG markers presence Markers serve as identifiers of various structural parts of compressed data formats. All markers are assigned two-byte codes: an 0xFF byte followed by a byte which is not equal to 0 or 0xFF. [2] Excluding the reserved ones there is 39 valid codes. I'm not really sure how the markers inhibit feature is useful, but since some drivers use it let's assume it is needed. Likely a 32-bit bitmask control could be used for activating/deactivating markers, as it doesn't make sense for some of markers to be freely discarded from the compressed data. o V4L2_CID_JPEG_ACTIVE_MARKERS Following markers might be covered by this control, listed in Table E.1, [2]: APP0..15, COM, DHT, DQT, DAC and additionally DNL. There is still room for 10 additional markers which might be added if required. Are there limitation on the contents of the COM field? I.e., can it contain '\0' values? If not, then it can perhaps be represented by a string control. There is no limitation, valid values for each comment byte are 0..255, and the standard (B.2.4.5, p.43, [2]) says the interpretation is left to the application. Thus unfortunately the string control cannot be used here. The above list of
Re: Using MT9P031 digital sensor
On 2011-11-28 05:49, Laurent Pinchart wrote: Hi Gary, On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? OK, I'll give that a try get back to you. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
On 11/28/2011 01:39 PM, Hans Verkuil wrote: On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: On 11/28/2011 12:38 PM, Hans Verkuil wrote: On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: This control is intended for the video capture or memory-to-memory devices that are capable of setting up a per-pixel alpha component to some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to set the alpha component for all pixels to a value in range from 0 to 255. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/compat.xml | 11 Documentation/DocBook/media/v4l/controls.xml | 25 +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml| 7 - drivers/media/video/v4l2-ctrls.c |7 + include/linux/videodev2.h |6 ++-- 5 files changed, 45 insertions(+), 11 deletions(-) ... /* MPEG controls */ /* Keep the order of the 'case's the same as in videodev2.h! */ @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type, /* Max is calculated as RGB888 that is 2^24 */ *max = 0xFF; break; + case V4L2_CID_ALPHA_COMPONENT: + *type = V4L2_CTRL_TYPE_INTEGER; + *step = 1; + *min = 0; + *max = 0xff; + break; Hmm. Do we really want to fix the max value to 0xff? The bits assigned to the alpha component will vary between 1 (V4L2_PIX_FMT_RGB555X), 4 (V4L2_PIX_FMT_RGB444) or 8 (V4L2_PIX_FMT_RGB32). It wouldn't surprise me to see larger sizes as well in the future (e.g. 16 bits). I think the max value should be the largest alpha value the hardware can support. The application has to set it to the right value that corresponds to the currently chosen pixel format. The driver just copies the first N bits into the alpha value where N depends on the pixel format. what do you think? Yes, ideally the maximum value of the alpha control should be changing depending on the set colour format. Currently the maximum value of the control equals maximum alpha value for the fourcc of maximum colour depth (V4L2_PIX_FMT_RGB32). What I found missing was a method for changing the control range dynamically, without deleting and re-initializing the control handler. If we reinitalize whole control handler the previously set control values are lost. You can just change the maximum field of struct v4l2_ctrl on the fly like this: struct v4l2_ctrl *my_ctrl; v4l2_ctrl_lock(my_ctrl); my_ctrl-maximum = 10; if (my_ctrl-cur.val my_ctrl-maximum) my_ctrl-cur.val = my_ctrl-maximum; v4l2_ctrl_unlock(my_ctrl); Although this might warrant a v4l2_ctrl_update_range() function that does this for you. Because after a change like this a V4L2_EVENT_CTRL should also be sent. In any case, this functionality isn't hard to add. Just let me know if you need it and I can make a patch for this. Yes, it would be great if you could prepare a patch for v4l2_ctrl_update_range(). Then I could use it in the next iteration of the patches, instead of hacking at the driver. IIRC it's not the first time we needed changing the control range dynamically. -- Thanks! Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch v2] [media] saa7164: fix endian conversion in saa7164_bus_set()
The msg-command field is 32 bits, and we should fill it with a call
to cpu_to_le32(). The current code is broke on big endian systems.
On little endian systems it truncates the 32 bit value to 16 bits
which probably still works fine.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
v2: Mauro pointed out that I missed the conversion back to cpu endian.
This is a static checker bug. The current code is definitely broken on
big endian systems. I'm pretty sure my fix is correct, but I don't
have the hardware to test it.
diff --git a/drivers/media/video/saa7164/saa7164-bus.c
b/drivers/media/video/saa7164/saa7164-bus.c
index 466e1b0..a7f58a9 100644
--- a/drivers/media/video/saa7164/saa7164-bus.c
+++ b/drivers/media/video/saa7164/saa7164-bus.c
@@ -149,7 +149,7 @@ int saa7164_bus_set(struct saa7164_dev *dev, struct
tmComResInfo* msg,
saa7164_bus_verify(dev);
msg-size = cpu_to_le16(msg-size);
- msg-command = cpu_to_le16(msg-command);
+ msg-command = cpu_to_le32(msg-command);
msg-controlselector = cpu_to_le16(msg-controlselector);
if (msg-size dev-bus.m_wMaxReqSize) {
@@ -464,7 +464,7 @@ int saa7164_bus_get(struct saa7164_dev *dev, struct
tmComResInfo* msg,
peekout:
msg-size = le16_to_cpu(msg-size);
- msg-command = le16_to_cpu(msg-command);
+ msg-command = le32_to_cpu(msg-command);
msg-controlselector = le16_to_cpu(msg-controlselector);
ret = SAA_OK;
out:
signature.asc
Description: Digital signature
[PATCH] [media] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
From: Josh Wu josh...@atmel.com
This patch
- add ISI_MCK clock enable/disable code.
- change field name in isi_platform_data structure
Signed-off-by: Josh Wu josh...@atmel.com
[g.liakhovet...@gmx.de: fix label names]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
Guennadi,
Here is the pach form Josh and yourself about the Atmel ISI driver
modifications. I have rebased it on top of 3.2-rc3 (and tested it on
linux-next also).
I plan to submit the board/device related patches (2-3/3 of this series) to
the arm-soc tree real soon. Do you whant me to include this one or can you
schedulle an inclusion in mainline for 3.3?
Best regards,
drivers/media/video/atmel-isi.c | 31 +--
include/media/atmel-isi.h |4 +++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 8c775c5..5a7ab84 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -90,7 +90,10 @@ struct atmel_isi {
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
struct completion complete;
+ /* ISI peripherial clock */
struct clk *pclk;
+ /* ISI_MCK, feed to camera sensor to generate pixel clock */
+ struct clk *mck;
unsigned intirq;
struct isi_platform_data*pdata;
@@ -766,6 +769,12 @@ static int isi_camera_add_device(struct soc_camera_device
*icd)
if (ret)
return ret;
+ ret = clk_enable(isi-mck);
+ if (ret) {
+ clk_disable(isi-pclk);
+ return ret;
+ }
+
isi-icd = icd;
dev_dbg(icd-parent, Atmel ISI Camera driver attached to camera %d\n,
icd-devnum);
@@ -779,6 +788,7 @@ static void isi_camera_remove_device(struct
soc_camera_device *icd)
BUG_ON(icd != isi-icd);
+ clk_disable(isi-mck);
clk_disable(isi-pclk);
isi-icd = NULL;
@@ -874,7 +884,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd, u32 pixfmt)
if (isi-pdata-has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
- if (isi-pdata-isi_full_mode)
+ if (isi-pdata-full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -912,6 +922,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+ clk_put(isi-mck);
clk_put(isi-pclk);
kfree(isi);
@@ -930,7 +941,7 @@ static int __devinit atmel_isi_probe(struct platform_device
*pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
- if (!pdata || !pdata-data_width_flags) {
+ if (!pdata || !pdata-data_width_flags || !pdata-mck_hz) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -959,6 +970,19 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
INIT_LIST_HEAD(isi-video_buffer_list);
INIT_LIST_HEAD(isi-dma_desc_head);
+ /* Get ISI_MCK, provided by programmable clock or external clock */
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR_OR_NULL(isi-mck)) {
+ dev_err(dev, Failed to get isi_mck\n);
+ ret = isi-mck ? PTR_ERR(isi-mck) : -EINVAL;
+ goto err_clk_get;
+ }
+
+ /* Set ISI_MCK's frequency, it should be faster than pixel clock */
+ ret = clk_set_rate(isi-mck, pdata-mck_hz);
+ if (ret 0)
+ goto err_set_mck_rate;
+
isi-p_fb_descriptors = dma_alloc_coherent(pdev-dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-fb_descriptors_phys,
@@ -1034,6 +1058,9 @@ err_alloc_ctx:
isi-p_fb_descriptors,
isi-fb_descriptors_phys);
err_alloc_descriptors:
+err_set_mck_rate:
+ clk_put(isi-mck);
+err_clk_get:
kfree(isi);
err_alloc_isi:
clk_put(isi-pclk);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 26cece5..6568230 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -110,10 +110,12 @@ struct isi_platform_data {
u8 hsync_act_low;
u8 vsync_act_low;
u8 pclk_act_falling;
- u8 isi_full_mode;
+ u8 full_mode;
u32 data_width_flags;
/* Using for ISI_CFG1 */
u32 frate;
+ /* Using for ISI_MCK */
+ u32 mck_hz;
};
#endif /* __ATMEL_ISI_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
Re: [PATCH] [media] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
Hi Nicolas
On Mon, 28 Nov 2011, Nicolas Ferre wrote:
From: Josh Wu josh...@atmel.com
This patch
- add ISI_MCK clock enable/disable code.
- change field name in isi_platform_data structure
Signed-off-by: Josh Wu josh...@atmel.com
[g.liakhovet...@gmx.de: fix label names]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks for the ack. All patches, affecting drivers/media include/media
should go via the media tree, I'll push this one along with others for 3.3
as appropriate.
Thanks
Guennadi
---
Guennadi,
Here is the pach form Josh and yourself about the Atmel ISI driver
modifications. I have rebased it on top of 3.2-rc3 (and tested it on
linux-next also).
I plan to submit the board/device related patches (2-3/3 of this series) to
the arm-soc tree real soon. Do you whant me to include this one or can you
schedulle an inclusion in mainline for 3.3?
Best regards,
drivers/media/video/atmel-isi.c | 31 +--
include/media/atmel-isi.h |4 +++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 8c775c5..5a7ab84 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -90,7 +90,10 @@ struct atmel_isi {
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
struct completion complete;
+ /* ISI peripherial clock */
struct clk *pclk;
+ /* ISI_MCK, feed to camera sensor to generate pixel clock */
+ struct clk *mck;
unsigned intirq;
struct isi_platform_data*pdata;
@@ -766,6 +769,12 @@ static int isi_camera_add_device(struct
soc_camera_device *icd)
if (ret)
return ret;
+ ret = clk_enable(isi-mck);
+ if (ret) {
+ clk_disable(isi-pclk);
+ return ret;
+ }
+
isi-icd = icd;
dev_dbg(icd-parent, Atmel ISI Camera driver attached to camera %d\n,
icd-devnum);
@@ -779,6 +788,7 @@ static void isi_camera_remove_device(struct
soc_camera_device *icd)
BUG_ON(icd != isi-icd);
+ clk_disable(isi-mck);
clk_disable(isi-pclk);
isi-icd = NULL;
@@ -874,7 +884,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd, u32 pixfmt)
if (isi-pdata-has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
- if (isi-pdata-isi_full_mode)
+ if (isi-pdata-full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -912,6 +922,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+ clk_put(isi-mck);
clk_put(isi-pclk);
kfree(isi);
@@ -930,7 +941,7 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
- if (!pdata || !pdata-data_width_flags) {
+ if (!pdata || !pdata-data_width_flags || !pdata-mck_hz) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -959,6 +970,19 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
INIT_LIST_HEAD(isi-video_buffer_list);
INIT_LIST_HEAD(isi-dma_desc_head);
+ /* Get ISI_MCK, provided by programmable clock or external clock */
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR_OR_NULL(isi-mck)) {
+ dev_err(dev, Failed to get isi_mck\n);
+ ret = isi-mck ? PTR_ERR(isi-mck) : -EINVAL;
+ goto err_clk_get;
+ }
+
+ /* Set ISI_MCK's frequency, it should be faster than pixel clock */
+ ret = clk_set_rate(isi-mck, pdata-mck_hz);
+ if (ret 0)
+ goto err_set_mck_rate;
+
isi-p_fb_descriptors = dma_alloc_coherent(pdev-dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-fb_descriptors_phys,
@@ -1034,6 +1058,9 @@ err_alloc_ctx:
isi-p_fb_descriptors,
isi-fb_descriptors_phys);
err_alloc_descriptors:
+err_set_mck_rate:
+ clk_put(isi-mck);
+err_clk_get:
kfree(isi);
err_alloc_isi:
clk_put(isi-pclk);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 26cece5..6568230 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -110,10 +110,12 @@ struct isi_platform_data {
u8 hsync_act_low;
u8 vsync_act_low;
u8 pclk_act_falling;
- u8 isi_full_mode;
+ u8 full_mode;
u32 data_width_flags;
/* Using for ISI_CFG1 */
u32 frate;
+ /* Using for ISI_MCK */
+ u32 mck_hz;
};
#endif /*
Re: [RFC/PATCH 1/3] v4l: Introduce integer menu controls
On Friday 25 November 2011 13:58:27 Laurent Pinchart wrote:
Hi Sakari,
On Friday 25 November 2011 13:56:50 Sakari Ailus wrote:
On Fri, Nov 25, 2011 at 01:43:12PM +0100, Laurent Pinchart wrote:
On Friday 25 November 2011 13:02:02 Sakari Ailus wrote:
On Fri, Nov 25, 2011 at 11:28:46AM +0100, Laurent Pinchart wrote:
On Thursday 24 November 2011 17:12:50 Sakari Ailus wrote:
...
@@ -1440,12 +1458,13 @@ struct v4l2_ctrl
*v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, u32 flags;
v4l2_ctrl_fill(id, name, type, min, max, step, def,
flags);
- if (type != V4L2_CTRL_TYPE_MENU) {
+ if (type != V4L2_CTRL_TYPE_MENU
+type != V4L2_CTRL_TYPE_INTEGER_MENU) {
handler_set_err(hdl, -EINVAL);
return NULL;
}
return v4l2_ctrl_new(hdl, ops, id, name, type,
- 0, max, mask, def, flags, qmenu,
NULL);
+0, max, mask, def, flags, qmenu, NULL,
NULL);
You pass NULL to the v4l2_ctrl_new() qmenu_int argument, which will
make the function fail for integer menu controls. Do you expect
standard integer menu controls to share a list of values ? If not,
what about modifying v4l2_ctrl_new_std_menu() to take a list of
values (or alternatively forbidding the function from being used
for integer menu controls) ?
We currently have no integer menu controls, let alone one which would
have a set of standard values. We need same functionality as in
v4l2_ctrl_get_menu() for integer menus when we add the first
standardised integer menu control. I think it could be added at that
time, or I could implement a v4l2_ctrl_get_integer_menu() which would
do nothing.
What do you think?
I was just wondering if we will ever have a standard menu control with
standard integer items. If that never happens, v4l2_ctrl_new_std_menu()
needs to either take a qmenu_int array, or reject integer menu controls
completely. I would thus delay adding the V4L2_CTRL_TYPE_INTEGER_MENU
check to the function as it wouldn't work anyway (or, alternatively, we
would add the qmenu_int argument now).
Either one, yes. I think I'll add a separate patch adding standard
integer menus and remove the check from this one.
There'll definitely be a need for them. For example, there are bit rate
menus in the standard menu type controls that ideally should be integers.
Sure, but I doubt that the bit rates themselves will be standard.
Actually, they are. MPEG audio level 1, 2, 3 and AC3 audio all have their own
standardized set of possible bitrates. If I had an integer menu at the time
I'm sure I would have used it.
Regards,
Hans
We won't change them but there will be others. Or I'd be very surprised
if there were not!
--
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-900H dvb-t regression(s)
Hi all, short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working. Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary. Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time. Based on git bisect: The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004 The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb commit f010dca2e52d8dcc0445d695192df19241afacdb Author: Stefan Ringel stefan.rin...@arcor.de Date: Mon May 9 16:53:58 2011 -0300 [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask move from tm6000_set_reg to tm6000_set_reg_mask Signed-off-by: Stefan Ringel stefan.rin...@arcor.de Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com While this commit appears rather innocent, it changes the way some registries are set. the original code did: read_reg... change value write_reg.. (unconditionally) the new code path: read_reg... calculate new value check if it is same if not, write_reg... So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again. something along those lines: diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..818f542 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, new_index = (buf[0] ~mask) | (index mask); - if (new_index == index) - return 0; +// if (new_index == index) +// return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, req, value, new_index, NULL, 0); but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point. In an poor attempt to be a good boy, I collected all the data here: http://fabbione.fedorapeople.org/dvblogs.tar.xz (NOTE: 76MB file, 101MB unpacked) The file contains 5 dirs: last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004 first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+ head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1 test2-change-set-reg-mask-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1+ and each directory has: dmesg scan_results tcpdump (tcpdump -i usbmod1 -w tcpdump) usbmon0u (cat /sys usbmod0u) captures are started before modprobe tm6000-dvb and stop after a scan -a 0 dk The testX are marked + as they contain the workaround mentioned above (test1 also adds a build workaround fixed a few commits later in the tree to unexport a symbol). Thanks Fabio -- 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] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
On 11/28/2011 02:50 PM, Guennadi Liakhovetski :
Hi Nicolas
On Mon, 28 Nov 2011, Nicolas Ferre wrote:
From: Josh Wu josh...@atmel.com
This patch
- add ISI_MCK clock enable/disable code.
- change field name in isi_platform_data structure
Signed-off-by: Josh Wu josh...@atmel.com
[g.liakhovet...@gmx.de: fix label names]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks for the ack. All patches, affecting drivers/media include/media
should go via the media tree, I'll push this one along with others for 3.3
as appropriate.
That is just great!
On my side, I will take care of the device/board code through
at91/arm-soc trees...
Thanks, best regards,
---
Guennadi,
Here is the pach form Josh and yourself about the Atmel ISI driver
modifications. I have rebased it on top of 3.2-rc3 (and tested it on
linux-next also).
I plan to submit the board/device related patches (2-3/3 of this series) to
the arm-soc tree real soon. Do you whant me to include this one or can you
schedulle an inclusion in mainline for 3.3?
Best regards,
drivers/media/video/atmel-isi.c | 31 +--
include/media/atmel-isi.h |4 +++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c
b/drivers/media/video/atmel-isi.c
index 8c775c5..5a7ab84 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -90,7 +90,10 @@ struct atmel_isi {
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
struct completion complete;
+/* ISI peripherial clock */
struct clk *pclk;
+/* ISI_MCK, feed to camera sensor to generate pixel clock */
+struct clk *mck;
unsigned intirq;
struct isi_platform_data*pdata;
@@ -766,6 +769,12 @@ static int isi_camera_add_device(struct
soc_camera_device *icd)
if (ret)
return ret;
+ret = clk_enable(isi-mck);
+if (ret) {
+clk_disable(isi-pclk);
+return ret;
+}
+
isi-icd = icd;
dev_dbg(icd-parent, Atmel ISI Camera driver attached to camera %d\n,
icd-devnum);
@@ -779,6 +788,7 @@ static void isi_camera_remove_device(struct
soc_camera_device *icd)
BUG_ON(icd != isi-icd);
+clk_disable(isi-mck);
clk_disable(isi-pclk);
isi-icd = NULL;
@@ -874,7 +884,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd, u32 pixfmt)
if (isi-pdata-has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
-if (isi-pdata-isi_full_mode)
+if (isi-pdata-full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -912,6 +922,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+clk_put(isi-mck);
clk_put(isi-pclk);
kfree(isi);
@@ -930,7 +941,7 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
-if (!pdata || !pdata-data_width_flags) {
+if (!pdata || !pdata-data_width_flags || !pdata-mck_hz) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -959,6 +970,19 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
INIT_LIST_HEAD(isi-video_buffer_list);
INIT_LIST_HEAD(isi-dma_desc_head);
+/* Get ISI_MCK, provided by programmable clock or external clock */
+isi-mck = clk_get(dev, isi_mck);
+if (IS_ERR_OR_NULL(isi-mck)) {
+dev_err(dev, Failed to get isi_mck\n);
+ret = isi-mck ? PTR_ERR(isi-mck) : -EINVAL;
+goto err_clk_get;
+}
+
+/* Set ISI_MCK's frequency, it should be faster than pixel clock */
+ret = clk_set_rate(isi-mck, pdata-mck_hz);
+if (ret 0)
+goto err_set_mck_rate;
+
isi-p_fb_descriptors = dma_alloc_coherent(pdev-dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-fb_descriptors_phys,
@@ -1034,6 +1058,9 @@ err_alloc_ctx:
isi-p_fb_descriptors,
isi-fb_descriptors_phys);
err_alloc_descriptors:
+err_set_mck_rate:
+clk_put(isi-mck);
+err_clk_get:
kfree(isi);
err_alloc_isi:
clk_put(isi-pclk);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 26cece5..6568230 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -110,10 +110,12 @@ struct isi_platform_data {
u8 hsync_act_low;
u8 vsync_act_low;
u8 pclk_act_falling;
-u8 isi_full_mode;
+u8 full_mode;
u32 data_width_flags;
/* Using for ISI_CFG1
Re: [PATCH] em28xx: Add Terratec Cinergy HTC Stick
Hi folks, just a few quetstions: 1. Why is the device named EM2884_BOARD_CINERGY_HTC_STICK and not EM2884_BOARD_TERRATEC_HTC_STICK like all the other devices from that vendor? Looks inconsistent to me. 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a NXP TDA18271 as used tuner for H5 and HTC Stick devices. I dont have any experience in this kind of stuff but i am just asking. Regads, Jens ___ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 -- 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] omap3isp: video: Don't WARN() on unknown pixel formats
Thanks for the patch, Laurent!
On Mon, Nov 28, 2011 at 12:37:34PM +0100, Laurent Pinchart wrote:
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
---
drivers/media/video/omap3isp/ispvideo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index d100072..ffe7ce9 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const struct
v4l2_pix_format *pix,
mbus-width = pix-width;
mbus-height = pix-height;
- for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected if no
+ * match is found.
+ */
+ for (i = 0; i ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus-code = formats[i].code;
mbus-colorspace = pix-colorspace;
mbus-field = pix-field;
In case of setting or trying an invalid format, instead of selecting a
default format, shouldn't we leave the format unchanced --- the current
setting is valid after all.
--
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: [PATCH] [media] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
On Mon, Nov 28, 2011 at 02:34:44PM +0100, Nicolas Ferre wrote: From: Josh Wu josh...@atmel.com This patch - add ISI_MCK clock enable/disable code. - change field name in isi_platform_data structure Signed-off-by: Josh Wu josh...@atmel.com [g.liakhovet...@gmx.de: fix label names] Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- Guennadi, Here is the pach form Josh and yourself about the Atmel ISI driver modifications. I have rebased it on top of 3.2-rc3 (and tested it on linux-next also). I plan to submit the board/device related patches (2-3/3 of this series) to the arm-soc tree real soon. Do you whant me to include this one or can you schedulle an inclusion in mainline for 3.3? While you're doing this, why not also prepare for the common clk API by adding support for clk_prepare()/clk_unprepare() to these drivers? We are actually now at the point where we should be saying a firm no to any new introductions of clk_enable()/clk_disable() without there being corresponding clk_prepare()/clk_unprepare() calls for that clk. -- 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] em28xx: Add Terratec Cinergy HTC Stick
Hello On 11/28/2011 05:41 PM, Jens Erdmann wrote: just a few quetstions: 1. Why is the device named EM2884_BOARD_CINERGY_HTC_STICK and not EM2884_BOARD_TERRATEC_HTC_STICK like all the other devices from that vendor? Looks inconsistent to me. Developer have just chosen some value. Maybe he have not looked so carefully about naming. Feel free to fix :) I think correct name is something chip version + board + vendor name + device name and model. If name goes something like very long it could be shortened. 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a NXP TDA18271 as used tuner for H5 and HTC Stick devices. I dont have any experience in this kind of stuff but i am just asking. DVB device contain logically three chips. Those are; 1. interface chip (USB, PCI) 2. demodulator 3. tuner Those parts can be integrated even as one silicon (called 3-in-1). Very commonly it seen combination 1.+2. in one chip and 3. in other == total 2 chips. EM2884 is interface chip. It is called usually DVB USB bridge since it transfers bits from demod to computer. TDA18271 is tuner. On the other side of chip is antenna connected as signal input and output is IF (intermediate frequency). Tuner can be thought as chip that transfers signal from RF (radio frequency) to IF (intermediate frequency). Demodulator then takes that IF from tuner and encodes bits out from signal. Interface between demodulator and bridge is bit interface and it is called MPEG2 TS (transport stream) interface. There is also second interface for controlling each chip. That interface is usually I2C bus. Each chip (demod and tuner) is connected to the I2C-bus-adapter which is part of bridge. All command to chips are send using that I2C interface. regards Antti -- http://palosaari.fi/ -- 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: [trivial PATCH] omap24xxcam-dma: Fix logical test
On Sun, Nov 27, 2011 at 11:42:15AM -0800, Joe Perches wrote: Likely misuse of vs . Signed-off-by: Joe Perches j...@perches.com Thanks, Joe! Acked-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/media/video/omap24xxcam-dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap24xxcam-dma.c b/drivers/media/video/omap24xxcam-dma.c index 1d54b86..3ea38a8 100644 --- a/drivers/media/video/omap24xxcam-dma.c +++ b/drivers/media/video/omap24xxcam-dma.c @@ -506,7 +506,7 @@ int omap24xxcam_sgdma_queue(struct omap24xxcam_sgdma *sgdma, unsigned long flags; struct sgdma_state *sg_state; - if ((sglen 0) || ((sglen 0) !sglist)) + if ((sglen 0) || ((sglen 0) !sglist)) return -EINVAL; spin_lock_irqsave(sgdma-lock, flags); -- 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 -- 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: [PATCH] em28xx: Add Terratec Cinergy HTC Stick
Hello Jens, On 28.11.2011 16:41, Jens Erdmann wrote: Hi folks, just a few quetstions: 1. Why is the device named EM2884_BOARD_CINERGY_HTC_STICK and not EM2884_BOARD_TERRATEC_HTC_STICK like all the other devices from that vendor? Looks inconsistent to me. that's because it's the product name. Even though TERRATEC is the vendor, the TERRATEC series of devices is different from the Cinergy series (mostly due to software bundles, IMHO). See their homepage for details. So, TERRATEC_HTC_STICK would be wrong. You could change it to TERRATEC_CINERGY_HTC_STICK, if it's important to you. However, following the same logic, the TERRATEC H5 should then be called TERRATEC_TERRATEC_H5, which seems rather odd. Btw.: The em28xx driver wrongly lists the H5 as Terratec Cinergy H5. 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a NXP TDA18271 as used tuner for H5 and HTC Stick devices. I dont have any experience in this kind of stuff but i am just asking. That's right. Regards, Andreas -- 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: Problem with linux-3.1.3
Hi Laurent, Am Montag, 28. November 2011, 11:37:52 schrieb Laurent Pinchart: uvcvideo: Failed to submit URB 0 (-28). Same for using e.g. Google+ Hangouts which worked fine using v3.1. Any ideas what might be wrong? I'm tempted to blame http://git.kernel.org/?p=linux/kernel/git/stable/linux- stable.git;a=commit;h=f0cc710a6dec5b808a6f13f1f8853c094fce5f12. Could you please try reverting that patch and see if it fixes your issue ? That's it :-D I reverted f0cc710a6dec5b808a6f13f1f8853c094fce5f12 on-top of v3.1.3 and now the webcam is working again. Should this go to v3.1.4 and 3.2? Thanks... HS -- 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: Problem with linux-3.1.3
Hi Hendrik, On Monday 28 November 2011 18:10:38 Hendrik Sattler wrote: Hi Laurent, Am Montag, 28. November 2011, 11:37:52 schrieb Laurent Pinchart: uvcvideo: Failed to submit URB 0 (-28). Same for using e.g. Google+ Hangouts which worked fine using v3.1. Any ideas what might be wrong? I'm tempted to blame http://git.kernel.org/?p=linux/kernel/git/stable/linux- stable.git;a=commit;h=f0cc710a6dec5b808a6f13f1f8853c094fce5f12. Could you please try reverting that patch and see if it fixes your issue ? That's it :-D I reverted f0cc710a6dec5b808a6f13f1f8853c094fce5f12 on-top of v3.1.3 and now the webcam is working again. Should this go to v3.1.4 and 3.2? The problem has just been reported to the linux-usb mailing list (uvcvideo: Failed to submit URB 0 (-28) mail thread). Let's see what will happen. -- 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 query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
Hi Laurent, Fortunately my laptop is alive now so I'm sending you lsusb output. About reverting commit - will try bit later. Best regards, Alex On 11/28/2011 01:35 PM, Laurent Pinchart wrote: Hi Alex, On Sunday 27 November 2011 21:01:23 Alex wrote: Hi guys, I'm using kernel 3.2-rc3 and get following in dmesg on every try to use thinkpad integrated camera (here I did rmmod and modprobe before test): [ 9481.258170] usbcore: deregistering interface driver uvcvideo [ 9481.296659] uvcvideo: Failed to submit URB 0 (-28). [ 9481.296677] uvcvideo 1-1.6:1.1: resume error -28 [ 9490.117546] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b221) [ 9490.119166] input: Integrated Camera as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input13 [ 9490.119298] usbcore: registered new interface driver uvcvideo [ 9490.119302] USB Video Class driver (1.1.1) [ 9498.101683] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 9498.113603] uvcvideo: Failed to submit URB 0 (-28). Those two errors might be unrelated. For the second one, I'm tempted to blame http://git.kernel.org/?p=linux/kernel/git/stable/linux- stable.git;a=commit;h=f0cc710a6dec5b808a6f13f1f8853c094fce5f12. Could you please try reverting it, and see if it fixes your issue ? If so, let's report that to the linux-usb mailing list. For the first one, could you please send me the lsusb -v output for your webcam ? Couldn't open device, some information will be missing Couldn't open device, some information will be missing Couldn't open device, some information will be missing Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice3.02 iManufacturer 3 iProduct2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice3.02 iManufacturer 3 iProduct2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass 0
Re: [RFC] JPEG encoders control class
Hans Verkuil ha scritto:
On Saturday 12 November 2011 20:46:25 Sylwester Nawrocki wrote:
Hi all,
This RFC is discussing the current support of JPEG encoders in V4L2 and
a proposal of new JPEG control class.
Motivation
==
JPEG encoder control is also required at the sub-device level, but
currently there are only defined ioctls in regular V4L2 device API. It
doesn't seem to make sense for these current ioctls to be inherited by
sub-device nodes, since they're not generic enough, incomplete and rather
not compliant with JFIF JPEG standard [2], [3].
Current implementation
==
Currently two ioctls are available [4]:
#define VIDIOC_G_JPEGCOMP_IOR('V', 61, struct v4l2_jpegcompression)
#define VIDIOC_S_JPEGCOMP_IOW('V', 62, struct v4l2_jpegcompression)
And the corresponding data structure is defined as:
struct v4l2_jpegcompression {
int quality;
int APPn; /* Number of APP segment to be written,
* must be 0..15 */
int APP_len; /* Length of data in JPEG APPn segment */
char APP_data[60]; /* Data in the JPEG APPn segment. */
int COM_len; /* Length of data in JPEG COM segment */
char COM_data[60]; /* Data in JPEG COM segment */
__u32 jpeg_markers; /* Which markers should go into the JPEG
* output. Unless you exactly know what
* you do, leave them untouched.
* Inluding less markers will make the
* resulting code smaller, but there will
* be fewer applications which can read it.
* The presence of the APP and COM marker
* is influenced by APP_len and COM_len
* ONLY, not by this property! */
#define V4L2_JPEG_MARKER_DHT (13)/* Define Huffman Tables */
#define V4L2_JPEG_MARKER_DQT (14)/* Define Quantization Tables */
#define V4L2_JPEG_MARKER_DRI (15)/* Define Restart Interval */
#define V4L2_JPEG_MARKER_COM (16)/* Comment segment */
#define V4L2_JPEG_MARKER_APP (17)/* App segment, driver will
* allways use APP0 */
};
What are the issues with such an implementation ?
These ioctls don't allow to re-program the quantization and Huffman tables
(DQT, DHT). Additionally, the standard valid segment length for the
application defined APPn and the comment COM segment is 2...65535, while
currently this is limited to 60 bytes.
Therefore APP_data and COM_data, rather than fixed size arrays, should be
pointers to a variable length buffer.
Only two drivers upstream really use VIDIOC_[S/G]_JPEGCOMP ioctls for
anything more than compression quality query/control. It might make sense
to create separate control for image quality and to obsolete the
v4l2_jpegcompressin::quality field.
Below is a brief review of usage of VIDIOC_[S/G]_JPEGCOMP ioctls in current
mainline drivers. Listed are parts of struct v4l2_jpegcompression used in
each case.
cpia2
-
vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality ignored, returns fixed value (80)
- uses APP_data/len, COM_data/len
- markers (only DHT can be disabled by the applications)
zoran
-
vidioc_g_jpegcomp, vidioc_s_jpegcomp
- compression quality, values 5...100, used only to calculate buffer size
- APP_data/len, COM_data/len
- markers field used to control inclusion of selected JPEG markers
in the output buffer
et61x251, sn9c102, s2255drv.c
-
Note that et61x251 and sn9c102 are going to be deprecated and removed at some
time in the future (gspca will support these devices).
Has this been discussed yet? Also, last time I tried the gspca driver
with a number of V4L2-compliant applications, it did not support at all
or work well for all the sn9c1xx-based devices I have here, which are
both controllers and sensors the manufacturer sent to me when developing
the driver with their collaboration. I also don't understand why the
gspca driver has been accepted in the mainline kernel in the first
place, despite the fact the sn9c1xx has been present in the kernel since
long time and already supported many devices at the time the gspca was
submitted. Maybe it's better to remove the duplicate code form the gspca
driver and add the different parts (if any) to the sn9c1xx.
Regards
Luca
--
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: ERRORS
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:Mon Nov 28 19:00:17 CET 2011 git hash:d95d7b91b4c6e3dfe94c07cd04993f60c887073d gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS 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: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-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-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
Re: uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
Hi Alex, On Monday 28 November 2011 19:04:22 Alex wrote: Hi Laurent, Fortunately my laptop is alive now so I'm sending you lsusb output. Thanks. Would you mind re-running lsusb -v -d '04f2:b221' as root ? What laptop brand/model is the camera embedded in ? About reverting commit - will try bit later. I've received reports that reverting the commit helps. A proper patch has also been posted to the linux-usb mailing list (EHCI : Fix a regression in the ISO scheduler). It would be nice if you could check whether that fixes your first issue as well. -- 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 query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
On 11/28/2011 10:08 PM, Laurent Pinchart wrote:
Hi Alex,
On Monday 28 November 2011 19:04:22 Alex wrote:
Hi Laurent,
Fortunately my laptop is alive now so I'm sending you lsusb output.
Thanks. Would you mind re-running lsusb -v -d '04f2:b221' as root ? What
laptop brand/model is the camera embedded in ?
About reverting commit - will try bit later.
I've received reports that reverting the commit helps. A proper patch has also
been posted to the linux-usb mailing list (EHCI : Fix a regression in the ISO
scheduler). It would be nice if you could check whether that fixes your first
issue as well.
Laurent,
That is lsusb output you asked. Laptop is Thinkpad T420s. Camera works
OK with 3.1.x kernel BTW.
Could you send this fix patch to me please?
Thanks,
Alex
Bus 001 Device 003: ID 04f2:b221 Chicony Electronics Co., Ltd
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x04f2 Chicony Electronics Co., Ltd
idProduct 0xb221
bcdDevice7.52
iManufacturer 1 Chicony Electronics Co., Ltd.
iProduct2 Integrated Camera
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 800
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 200mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 4 Integrated Camera
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 4 Integrated Camera
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 78
dwClockFrequency 30.00MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 4
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x00040a0e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
Zoom (Absolute)
PanTilt (Absolute)
Privacy
VideoControl Interface Descriptor:
bLength11
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 2
bSourceID 1
wMaxMultiplier 0
bControlSize2
bmControls 0x157f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Backlight Compensation
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1b
None
NTSC - 525/60
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength27
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 3
guidExtensionCode {0a3e1874-8254-1a48-b402-48b8b8c49cc8}
bNumControl11
bNrPins 1
baSourceID( 0) 2
bControlSize2
bmControls( 0) 0xff
bmControls( 1) 0x07
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 3
iTerminal 0
Re: Status of RTL283xU support?
On Sat, Nov 26, 2011 at 17:20, Maik Zumstrull m...@zumstrull.net wrote: FYI, someone has contacted me off-list to point out that the newest(?) Realtek tree for these devices is available online: Gave it a spin, built out of tree against Debian's Linux 3.0 binaries. Basically works, you can get a signal, but has crashed my system a few times. Removed it again. YMMV. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] tm6000: bugfix interrupt reset
From: Stefan Ringel linu...@stefanringel.de
Signed-off-by: Stefan Ringel linu...@stefanringel.de
---
drivers/media/video/tm6000/tm6000-core.c | 49 -
drivers/media/video/tm6000/tm6000-video.c | 21 ++--
2 files changed, 17 insertions(+), 53 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-core.c
b/drivers/media/video/tm6000/tm6000-core.c
index c007e6d..920299e 100644
--- a/drivers/media/video/tm6000/tm6000-core.c
+++ b/drivers/media/video/tm6000/tm6000-core.c
@@ -599,55 +599,6 @@ int tm6000_init(struct tm6000_core *dev)
return rc;
}
-int tm6000_reset(struct tm6000_core *dev)
-{
- int pipe;
- int err;
-
- msleep(500);
-
- err = usb_set_interface(dev-udev, dev-isoc_in.bInterfaceNumber, 0);
- if (err 0) {
- tm6000_err(failed to select interface %d, alt. setting 0\n,
- dev-isoc_in.bInterfaceNumber);
- return err;
- }
-
- err = usb_reset_configuration(dev-udev);
- if (err 0) {
- tm6000_err(failed to reset configuration\n);
- return err;
- }
-
- if ((dev-quirks TM6000_QUIRK_NO_USB_DELAY) == 0)
- msleep(5);
-
- /*
-* Not all devices have int_in defined
-*/
- if (!dev-int_in.endp)
- return 0;
-
- err = usb_set_interface(dev-udev, dev-isoc_in.bInterfaceNumber, 2);
- if (err 0) {
- tm6000_err(failed to select interface %d, alt. setting 2\n,
- dev-isoc_in.bInterfaceNumber);
- return err;
- }
-
- msleep(5);
-
- pipe = usb_rcvintpipe(dev-udev,
- dev-int_in.endp-desc.bEndpointAddress
USB_ENDPOINT_NUMBER_MASK);
-
- err = usb_clear_halt(dev-udev, pipe);
- if (err 0) {
- tm6000_err(usb_clear_halt failed: %d\n, err);
- return err;
- }
-
- return 0;
-}
int tm6000_set_audio_bitrate(struct tm6000_core *dev, int bitrate)
{
diff --git a/drivers/media/video/tm6000/tm6000-video.c
b/drivers/media/video/tm6000/tm6000-video.c
index 1e5ace0..4db3535 100644
--- a/drivers/media/video/tm6000/tm6000-video.c
+++ b/drivers/media/video/tm6000/tm6000-video.c
@@ -1609,12 +1609,25 @@ static int tm6000_release(struct file *file)
tm6000_uninit_isoc(dev);
+ /* Stop interrupt USB pipe */
+ tm6000_ir_int_stop(dev);
+
+ usb_reset_configuration(dev-udev);
+
+ if (dev-int_in)
+ usb_set_interface(dev-udev,
+ dev-isoc_in.bInterfaceNumber,
+ 2);
+ else
+ usb_set_interface(dev-udev,
+ dev-isoc_in.bInterfaceNumber,
+ 0);
+
+ /* Start interrupt USB pipe */
+ tm6000_ir_int_start(dev);
+
if (!fh-radio)
videobuf_mmap_free(fh-vb_vidq);
-
- err = tm6000_reset(dev);
- if (err 0)
- dev_err(vdev-dev, reset failed: %d\n, err);
}
kfree(fh);
--
1.7.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] tm6000: remove experimental depends
From: Stefan Ringel linu...@stefanringel.de Signed-off-by: Stefan Ringel linu...@stefanringel.de --- drivers/media/video/tm6000/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/tm6000/Kconfig b/drivers/media/video/tm6000/Kconfig index 114eec8..a43b77a 100644 --- a/drivers/media/video/tm6000/Kconfig +++ b/drivers/media/video/tm6000/Kconfig @@ -1,6 +1,6 @@ config VIDEO_TM6000 tristate TV Master TM5600/6000/6010 driver - depends on VIDEO_DEV I2C INPUT RC_CORE USB EXPERIMENTAL + depends on VIDEO_DEV I2C INPUT RC_CORE USB select VIDEO_TUNER select MEDIA_TUNER_XC2028 select MEDIA_TUNER_XC5000 @@ -16,7 +16,7 @@ config VIDEO_TM6000 config VIDEO_TM6000_ALSA tristate TV Master TM5600/6000/6010 audio support - depends on VIDEO_TM6000 SND EXPERIMENTAL + depends on VIDEO_TM6000 SND select SND_PCM ---help--- This is a video4linux driver for direct (DMA) audio for @@ -27,7 +27,7 @@ config VIDEO_TM6000_ALSA config VIDEO_TM6000_DVB tristate DVB Support for tm6000 based TV cards - depends on VIDEO_TM6000 DVB_CORE USB EXPERIMENTAL + depends on VIDEO_TM6000 DVB_CORE USB select DVB_ZL10353 ---help--- This adds support for DVB cards based on the tm5600/tm6000 chip. -- 1.7.7 -- 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 4/5] tm6000: bugfix bulk transfer
From: Stefan Ringel linu...@stefanringel.de
Signed-off-by: Stefan Ringel linu...@stefanringel.de
---
drivers/media/video/tm6000/tm6000-dvb.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-dvb.c
b/drivers/media/video/tm6000/tm6000-dvb.c
index 5e6c129..db6a561 100644
--- a/drivers/media/video/tm6000/tm6000-dvb.c
+++ b/drivers/media/video/tm6000/tm6000-dvb.c
@@ -89,9 +89,19 @@ static void tm6000_urb_received(struct urb *urb)
int ret;
struct tm6000_core *dev = urb-context;
- if (urb-status != 0)
+ switch (urb-status) {
+ case 0:
+ case -ETIMEDOUT:
+ break;
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ESHUTDOWN:
+ return;
+ default:
print_err_status(dev, 0, urb-status);
- else if (urb-actual_length 0)
+ }
+
+ if (urb-actual_length 0)
dvb_dmx_swfilter(dev-dvb-demux, urb-transfer_buffer,
urb-actual_length);
@@ -151,7 +161,7 @@ static int tm6000_start_stream(struct tm6000_core *dev)
printk(KERN_ERR tm6000: pipe resetted\n);
/* mutex_lock(tm6000_driver.open_close_mutex); */
- ret = usb_submit_urb(dvb-bulk_urb, GFP_KERNEL);
+ ret = usb_submit_urb(dvb-bulk_urb, GFP_ATOMIC);
/* mutex_unlock(tm6000_driver.open_close_mutex); */
if (ret) {
--
1.7.7
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] tm6000: bugfix register setting
From: Stefan Ringel linu...@stefanringel.de Signed-off-by: Stefan Ringel linu...@stefanringel.de --- drivers/media/video/tm6000/tm6000-core.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..c007e6d 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -125,14 +125,14 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, u8 new_index; rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR, req, - value, index, buf, 1); + value, 0, buf, 1); if (rc 0) return rc; new_index = (buf[0] ~mask) | (index mask); - if (new_index == index) + if (new_index == buf[0]) return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, -- 1.7.7 -- 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 5/5] tm6000: bugfix data check
From: Stefan Ringel linu...@stefanringel.de
beholder use a map with 3 bytes, but many rc maps have 2 bytes, so I add a
workaround for beholder rc.
Signed-off-by: Stefan Ringel linu...@stefanringel.de
---
drivers/media/video/tm6000/tm6000-input.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-input.c
b/drivers/media/video/tm6000/tm6000-input.c
index 405d127..ae7772e 100644
--- a/drivers/media/video/tm6000/tm6000-input.c
+++ b/drivers/media/video/tm6000/tm6000-input.c
@@ -178,9 +178,21 @@ static int default_polling_getkey(struct tm6000_IR *ir,
poll_result-rc_data = ir-urb_data[0];
break;
case RC_TYPE_NEC:
- if (ir-urb_data[1] == ((ir-key_addr 8) 0xff)) {
+ switch (dev-model) {
+ case 10:
+ case 11:
+ case 14:
+ case 15:
+ if (ir-urb_data[1] ==
+ ((ir-key_addr 8) 0xff)) {
+ poll_result-rc_data =
+ ir-urb_data[0]
+ | ir-urb_data[1] 8;
+ }
+ break;
+ default:
poll_result-rc_data = ir-urb_data[0]
- | ir-urb_data[1] 8;
+ | ir-urb_data[1] 8;
}
break;
default:
@@ -238,8 +250,6 @@ static void tm6000_ir_handle_key(struct tm6000_IR *ir)
return;
}
- dprintk(ir-get_key result data=%04x\n, poll_result.rc_data);
-
if (ir-pwled) {
if (ir-pwledcnt = PWLED_OFF) {
ir-pwled = 0;
@@ -250,6 +260,7 @@ static void tm6000_ir_handle_key(struct tm6000_IR *ir)
}
if (ir-key) {
+ dprintk(ir-get_key result data=%04x\n, poll_result.rc_data);
rc_keydown(ir-rc, poll_result.rc_data, 0);
ir-key = 0;
ir-pwled = 1;
@@ -333,7 +344,7 @@ int tm6000_ir_int_start(struct tm6000_core *dev)
ir-int_urb-transfer_buffer, size,
tm6000_ir_urb_received, dev,
dev-int_in.endp-desc.bInterval);
- err = usb_submit_urb(ir-int_urb, GFP_KERNEL);
+ err = usb_submit_urb(ir-int_urb, GFP_ATOMIC);
if (err) {
kfree(ir-int_urb-transfer_buffer);
usb_free_urb(ir-int_urb);
--
1.7.7
--
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-900H dvb-t regression(s)
On 28-11-2011 12:41, Fabio M. Di Nitto wrote: Hi all, short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working. Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary. Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time. Based on git bisect: The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004 The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb commit f010dca2e52d8dcc0445d695192df19241afacdb Author: Stefan Ringelstefan.rin...@arcor.de Date: Mon May 9 16:53:58 2011 -0300 [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask move from tm6000_set_reg to tm6000_set_reg_mask Signed-off-by: Stefan Ringelstefan.rin...@arcor.de Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com While this commit appears rather innocent, it changes the way some registries are set. the original code did: read_reg... change value write_reg.. (unconditionally) the new code path: read_reg... calculate new value check if it is same if not, write_reg... So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again. something along those lines: diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..818f542 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, new_index = (buf[0] ~mask) | (index mask); - if (new_index == index) - return 0; +// if (new_index == index) +// return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, req, value, new_index, NULL, 0); but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point. Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result, it will print: [ 7867.776612] tm6000: Found Generic tm6010 board [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7867.958753] tm6000 #1: i2c eeprom 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.075698] tm6000 #1: i2c eeprom 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.193607] tm6000 #1: i2c eeprom 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.310546] tm6000 #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.427507] tm6000 #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.52] tm6000 #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.662375] tm6000 #1: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.779319] tm6000 #1: i2c eeprom 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7868.896238] tm6000 #1: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.013195] tm6000 #1: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.130135] tm6000 #1: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.247069] tm6000 #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.363981] tm6000 #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.480948] tm6000 #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.597884] tm6000 #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 7869.707769] Device has eeprom but is currently unknown and the device will be miss-detected. You can fix it by forcing the driver to use card=9 via modprobe option. Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode. In an poor attempt to be a good boy, I collected all the data here: http://fabbione.fedorapeople.org/dvblogs.tar.xz (NOTE: 76MB file, 101MB unpacked) The file contains 5 dirs: last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004 first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+ head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1
Re: uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
On 11/28/2011 10:20 PM, Laurent Pinchart wrote: Hi Alex, On Monday 28 November 2011 20:14:25 Alex wrote: On 11/28/2011 10:08 PM, Laurent Pinchart wrote: On Monday 28 November 2011 19:04:22 Alex wrote: Fortunately my laptop is alive now so I'm sending you lsusb output. Thanks. Would you mind re-running lsusb -v -d '04f2:b221' as root ? What laptop brand/model is the camera embedded in ? About reverting commit - will try bit later. I've received reports that reverting the commit helps. A proper patch has also been posted to the linux-usb mailing list (EHCI : Fix a regression in the ISO scheduler). It would be nice if you could check whether that fixes your first issue as well. That is lsusb output you asked. Laptop is Thinkpad T420s. Camera works OK with 3.1.x kernel BTW. Thank you. Could you send this fix patch to me please? http://www.spinics.net/lists/linux-usb/msg54992.html It was the first hit on Google... Laurent, Seems this patch didn't help I recompiled kernel and still get same error: [ 101.100914] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 103.900163] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). [ 103.909735] uvcvideo: Failed to submit URB 0 (-28). [ 107.896939] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). 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
PATCH] for 3.3 it913x support for different tuner regs.
There appears to be differences in the tuner registers
on earlier IT9135 devices.
Using the current IT9137 settings cause corruptions on
some channels
This patch is in preparation for multi firmware loading and
current unsupported types.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c | 37 -
drivers/media/dvb/frontends/it913x-fe-priv.h | 20 ++
drivers/media/dvb/frontends/it913x-fe.c | 23 ---
drivers/media/dvb/frontends/it913x-fe.h |9 ++
4 files changed, 82 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index 24f04b4..d57e062 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -338,6 +338,31 @@ static int it913x_rc_query(struct dvb_usb_device *d)
return ret;
}
+static int ite_firmware_select(struct usb_device *udev,
+ struct dvb_usb_device_properties *props)
+{
+ int sw;
+ /* auto switch */
+ if (le16_to_cpu(udev-descriptor.idProduct) ==
+ USB_PID_ITETECH_IT9135)
+ sw = IT9135_V1_FW;
+ else
+ sw = IT9137_FW;
+
+ switch (sw) {
+ case IT9135_V1_FW:
+ it913x_config.firmware_ver = 0;
+ it913x_config.adc_x2 = 1;
+ break;
+ case IT9137_FW:
+ default:
+ it913x_config.firmware_ver = 0;
+ it913x_config.adc_x2 = 0;
+ }
+
+ return 0;
+}
+
#define TS_MPEG_PKT_SIZE 188
#define EP_LOW 21
#define TS_BUFFER_SIZE_PID (EP_LOW*TS_MPEG_PKT_SIZE)
@@ -392,6 +417,8 @@ static int it913x_identify_state(struct usb_device *udev,
props-adapter[1].fe[0].stream.u.bulk.buffersize =
props-adapter[0].fe[0].stream.u.bulk.buffersize;
+ ret = ite_firmware_select(udev, props);
+
if (firm_no 0) {
*cold = 0;
return 0;
@@ -421,10 +448,16 @@ static int it913x_identify_state(struct usb_device *udev,
if (it913x_config.dual_mode) {
ret |= it913x_wr_reg(udev, DEV_0, 0x4bfb, CHIP2_I2C_ADDR);
- ret |= it913x_wr_reg(udev, DEV_0, CLK_O_EN, 0x1);
+ if (it913x_config.firmware_ver == 1)
+ ret |= it913x_wr_reg(udev, DEV_0, 0xcfff, 0x1);
+ else
+ ret |= it913x_wr_reg(udev, DEV_0, CLK_O_EN, 0x1);
} else {
ret |= it913x_wr_reg(udev, DEV_0, 0x4bfb, 0x0);
- ret |= it913x_wr_reg(udev, DEV_0, CLK_O_EN, 0x0);
+ if (it913x_config.firmware_ver == 1)
+ ret |= it913x_wr_reg(udev, DEV_0, 0xcfff, 0x0);
+ else
+ ret |= it913x_wr_reg(udev, DEV_0, CLK_O_EN, 0x0);
}
*cold = 1;
diff --git a/drivers/media/dvb/frontends/it913x-fe-priv.h
b/drivers/media/dvb/frontends/it913x-fe-priv.h
index 836a5b8..ad2b644 100644
--- a/drivers/media/dvb/frontends/it913x-fe-priv.h
+++ b/drivers/media/dvb/frontends/it913x-fe-priv.h
@@ -230,6 +230,7 @@ static struct it913xset init_1[] = {
{PRO_LINK, LOCK3_OUT, {0x01}, 0x01},
{PRO_LINK, PADMISCDRSR, {0x01}, 0x01},
{PRO_LINK, PADMISCDR2, {0x00}, 0x01},
+ {PRO_DMOD, 0xec57, {0x00, 0x00}, 0x02},
{PRO_LINK, PADMISCDR4, {0x00}, 0x01}, /* Power up */
{PRO_LINK, PADMISCDR8, {0x00}, 0x01},
{0xff, 0x, {0x00}, 0x00} /* Terminating Entry */
@@ -1010,10 +1011,29 @@ static struct it913xset it9137_tuner_off[] = {
{PRO_DMOD, 0xfba8, {0x01}, 0x01}, /* Tuner Clock Off */
{PRO_DMOD, 0xec40, {0x00}, 0x01}, /* Power Down Tuner */
{PRO_DMOD, 0xec02, {0x3f, 0x1f, 0x3f, 0x3f}, 0x04},
+ {PRO_DMOD, 0xec06, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00}, 0x0c},
+ {PRO_DMOD, 0xec12, {0x00, 0x00, 0x00, 0x00}, 0x04},
+ {PRO_DMOD, 0xec17, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00}, 0x09},
+ {PRO_DMOD, 0xec22, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00}, 0x0a},
+ {PRO_DMOD, 0xec20, {0x00}, 0x01},
{PRO_DMOD, 0xec3f, {0x01}, 0x01},
{0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */
};
+static struct it913xset set_it9135_template[] = {
+ {PRO_DMOD, 0xee06, {0x00}, 0x01},
+ {PRO_DMOD, 0xec56, {0x00}, 0x01},
+ {PRO_DMOD, 0xec4c, {0x00}, 0x01},
+ {PRO_DMOD, 0xec4d, {0x00}, 0x01},
+ {PRO_DMOD, 0xec4e, {0x00}, 0x01},
+ {PRO_DMOD, 0x011e, {0x00}, 0x01}, /* Older Devices */
+ {PRO_DMOD, 0x011f, {0x00}, 0x01},
+ {0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */
+};
+
static struct it913xset set_it9137_template[] = {
{PRO_DMOD, 0xee06, {0x00}, 0x01},
[PATCH] it913x support for NEC extended keys
Add support for NEC extended keys.
The default remote has now changed to RC_MAP_MSI_DIGIVOX_III
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index d57e062..394bbf4 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -328,11 +328,13 @@ static int it913x_rc_query(struct dvb_usb_device *d)
if ((ibuf[2] + ibuf[3]) == 0xff) {
key = ibuf[2];
- key += ibuf[0] 8;
- deb_info(1, INT Key =%08x, key);
+ key += ibuf[0] 16;
+ key += ibuf[1] 8;
+ deb_info(1, NEC Extended Key =%08x, key);
if (d-rc_dev != NULL)
rc_keydown(d-rc_dev, key, 0);
}
+
mutex_unlock(d-i2c_mutex);
return ret;
@@ -701,7 +703,7 @@ static struct dvb_usb_device_properties it913x_properties =
{
.rc_query = it913x_rc_query,
.rc_interval= IT913X_POLL,
.allowed_protos = RC_TYPE_NEC,
- .rc_codes = RC_MAP_KWORLD_315U,
+ .rc_codes = RC_MAP_MSI_DIGIVOX_III,
},
.i2c_algo = it913x_i2c_algo,
.num_device_descs = 3,
@@ -748,5 +750,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.09);
+MODULE_VERSION(1.11);
MODULE_LICENSE(GPL);
--
1.7.7.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 1/2] [media] tm6000: Add a few missing bits to alsa
There are some properties found on em28xx, but not on tm6000. Add
them, in order to be more consistent.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-alsa.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-alsa.c
b/drivers/media/video/tm6000/tm6000-alsa.c
index 7d675c7..ddffd67 100644
--- a/drivers/media/video/tm6000/tm6000-alsa.c
+++ b/drivers/media/video/tm6000/tm6000-alsa.c
@@ -146,20 +146,21 @@ static int dsp_buffer_alloc(struct snd_pcm_substream
*substream, int size)
#define DEFAULT_FIFO_SIZE 4096
static struct snd_pcm_hardware snd_tm6000_digital_hw = {
- .info = SNDRV_PCM_INFO_MMAP |
+ .info = SNDRV_PCM_INFO_BATCH |
+ SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_MMAP_VALID,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
- .rates = SNDRV_PCM_RATE_CONTINUOUS,
+ .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT,
.rate_min = 48000,
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
.period_bytes_min = 64,
.period_bytes_max = 12544,
- .periods_min = 1,
+ .periods_min = 2,
.periods_max = 98,
.buffer_bytes_max = 62720 * 8,
};
@@ -181,6 +182,7 @@ static int snd_tm6000_pcm_open(struct snd_pcm_substream
*substream)
chip-substream = substream;
runtime-hw = snd_tm6000_digital_hw;
+ snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
return 0;
_error:
@@ -347,9 +349,13 @@ static int snd_tm6000_card_trigger(struct
snd_pcm_substream *substream, int cmd)
int err = 0;
switch (cmd) {
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: /* fall through */
+ case SNDRV_PCM_TRIGGER_RESUME: /* fall through */
case SNDRV_PCM_TRIGGER_START:
atomic_set(core-stream_started, 1);
break;
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH: /* fall through */
+ case SNDRV_PCM_TRIGGER_SUSPEND: /* fall through */
case SNDRV_PCM_TRIGGER_STOP:
atomic_set(core-stream_started, 0);
break;
@@ -371,6 +377,14 @@ static snd_pcm_uframes_t snd_tm6000_pointer(struct
snd_pcm_substream *substream)
return chip-buf_pos;
}
+static struct page *snd_pcm_get_vmalloc_page(struct snd_pcm_substream *subs,
+unsigned long offset)
+{
+ void *pageptr = subs-runtime-dma_area + offset;
+
+ return vmalloc_to_page(pageptr);
+}
+
/*
* operators
*/
@@ -383,6 +397,7 @@ static struct snd_pcm_ops snd_tm6000_pcm_ops = {
.prepare = snd_tm6000_prepare,
.trigger = snd_tm6000_card_trigger,
.pointer = snd_tm6000_pointer,
+ .page = snd_pcm_get_vmalloc_page,
};
/*
--
1.7.7.3
--
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 FOR 3.2 FIX] af9015: limit I2C access to keep FW happy
On 11/15/2011 12:25 AM, Malcolm Priestley wrote: I have tried this patch, while it initially got MythTV working, there is too many call backs and some failed to acquire the lock. The device became unstable on both single and dual devices. The callbacks af9015_af9013_read_status, af9015_af9013_init af9015_af9013_sleep had to be removed. I take your point, a call back can be an alternative. The patch didn't stop the firmware fails either. The af9015 usb bridge on the whole is so unstable in its early stages, especially on a cold boot and when the USB controller has another device on it, such as card reader or wifi device. I am, at the moment looking to see if the fails are due to interface 1 being claimed by HID. I just got af9013 rewrite ready. Feel free to test. http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/misc It reduces typical statistics polling load maybe 1/4 from the original. I see still small glitch when switching to channel. That seems to come from tuner driver I2C load. There is 3 tuners used for dual devices; MXL5005S, MXL5007T and TDA18271. I have only MXL5005S and MXL5007T dual devices here. MXL5005S is worse than MXL5007T but both makes still rather much I/O. regards Antti -- http://palosaari.fi/ -- 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] V4L: soc-camera: change order of removing device
Hi, On Tue, Nov 22, 2011 at 10:04 PM, Lei Wen lei...@marvell.com wrote: As our general practice, we use stream off before we close the video node. So that the drivers its stream off function would be called before its remove function. But for the case for ctrl+c, the program would be force closed. We have no chance to call that vb2 stream off from user space, but directly call the remove function in soc_camera. In that common code of soc_camera: ici-ops-remove(icd); if (ici-ops-init_videobuf2) vb2_queue_release(icd-vb2_vidq); It would first call the device remove function, then release vb2, in which stream off function is called. Thus it create different order for the driver. This patch change the order to make driver see the same sequence to make it happy. Signed-off-by: Lei Wen lei...@marvell.com --- drivers/media/video/soc_camera.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index b72580c..fdc6167 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -600,9 +600,9 @@ static int soc_camera_close(struct file *file) pm_runtime_suspend(icd-vdev-dev); pm_runtime_disable(icd-vdev-dev); - ici-ops-remove(icd); if (ici-ops-init_videobuf2) vb2_queue_release(icd-vb2_vidq); + ici-ops-remove(icd); soc_camera_power_off(icd, icl); } -- 1.7.0.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 Any comments? Thanks, Lei -- 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-900H dvb-t regression(s)
On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote: On 28-11-2011 12:41, Fabio M. Di Nitto wrote: Hi all, short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working. Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary. Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time. Based on git bisect: The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004 The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb commit f010dca2e52d8dcc0445d695192df19241afacdb Author: Stefan Ringelstefan.rin...@arcor.de Date: Mon May 9 16:53:58 2011 -0300 [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask move from tm6000_set_reg to tm6000_set_reg_mask Signed-off-by: Stefan Ringelstefan.rin...@arcor.de Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com While this commit appears rather innocent, it changes the way some registries are set. the original code did: read_reg... change value write_reg.. (unconditionally) the new code path: read_reg... calculate new value check if it is same if not, write_reg... So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again. something along those lines: diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..818f542 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, new_index = (buf[0] ~mask) | (index mask); - if (new_index == index) - return 0; +// if (new_index == index) +// return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, req, value, new_index, NULL, 0); but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point. Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result, it will print: [ 7867.776612] tm6000: Found Generic tm6010 board [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [SNIP] [ 7869.707769] Device has eeprom but is currently unknown and the device will be miss-detected. I don't think this was ever the case, but I can easily check the dmesg output that I collected. You can fix it by forcing the driver to use card=9 via modprobe option. Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode. Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable. As for the analog, I should be able to test it today. Fabio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: [media] dib7090: add the reference board TFE7090E
Hello Olivier Grenie,
This is a semi-automatic email about new static checker warnings.
The patch 6724a2f4f7a6: [media] dib7090: add the reference board
TFE7090E from Aug 5, 2011, leads to the following Smatch complaint:
drivers/media/dvb/frontends/dib0090.c +1146 dib0090_pwm_gain_reset()
error: we previously assumed 'state-rf_ramp' could be null (see line
1110)
drivers/media/dvb/frontends/dib0090.c
1109 if (state-config-is_dib7090e)
{
1110 if (state-rf_ramp ==
NULL)
^^
This test is new.
dib0090_set_rframp_pwm(state, rf_ramp_pwm_cband_7090e_sensitivity);
1112 else
1113
dib0090_set_rframp_pwm(state, state-rf_ramp);
1114 } else
1115
dib0090_set_rframp_pwm(state, rf_ramp_pwm_cband_7090);
1116 }
1117 } else {
1118 dib0090_set_rframp_pwm(state,
rf_ramp_pwm_cband);
1119 dib0090_set_bbramp_pwm(state,
bb_ramp_pwm_normal);
1120 }
1121 } else
1122 #endif
1123 #ifdef CONFIG_BAND_VHF
1124 if (state-current_band == BAND_VHF) {
1125 if (state-identity.in_soc) {
1126 dib0090_set_bbramp_pwm(state,
bb_ramp_pwm_normal_socs);
1127 } else {
1128 dib0090_set_rframp_pwm(state,
rf_ramp_pwm_vhf);
1129 dib0090_set_bbramp_pwm(state,
bb_ramp_pwm_normal);
1130 }
1131 } else
1132 #endif
1133 {
1134 if (state-identity.in_soc) {
1135 if (state-identity.version ==
SOC_8090_P1G_11R1 || state-identity.version == SOC_8090_P1G_21R1)
1136 dib0090_set_rframp_pwm(state,
rf_ramp_pwm_uhf_8090);
1137 else if (state-identity.version ==
SOC_7090_P1G_11R1 || state-identity.version == SOC_7090_P1G_21R1)
1138 dib0090_set_rframp_pwm(state,
rf_ramp_pwm_uhf_7090);
1139 dib0090_set_bbramp_pwm(state,
bb_ramp_pwm_normal_socs);
1140 } else {
1141 dib0090_set_rframp_pwm(state,
rf_ramp_pwm_uhf);
1142 dib0090_set_bbramp_pwm(state,
bb_ramp_pwm_normal);
1143 }
1144 }
1145
1146 if (state-rf_ramp[0] != 0)
^
This is the old dereference.
1147 dib0090_write_reg(state, 0x32, (3 11));
1148 else
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
