Omap3 ISP Recovering from SBL Overflow
Hello Laurent / everyone, I have an intermittent issue with the ISP driver, where occasionally I encounter an SBL overflow. Specifically the ISPSBL_PCR_CCDC_WBL_OVF bit is asserted. My hardware configuration uses the tvp5150 decoder chip in bt656 mode connected to DM3730 Silicon. The ISP is configured so that I am capturing frames directly from the CCDC output, without using any other ISP modules. From my digging so far, the SBL overflow seems to occur when closing the pipeline. The strange thing is that once the overflow occurs, I can no longer get any valid frames from the CCDC output, even on subsequent capture attempts using yavta / GStreamer. I can see the ISP interrupts occurring as normal and have verified that the decoder is indeed providing video correctly, however all of the buffers are marked with the error state and I just see endless "omap3isp: SBL Overflow (PCR = 0x0080)" messages in the kernel log. I have tried increasing the CCDC buffer memory allocation, but this doesn't appear to make any difference to the frequency of the occurrence. The TRM recommends that the SBL status bit is written back as a 1 to clear the error (which the ISP driver does indeed do), however it remains asserted and all I receive are blank buffers in the capture. I suspect the overflow is caused by the decoder running on during / after the stream off call, which causes the overflow. This isn't a major issue in itself, provided that the ISP can recover from the event. I am a little short on ideas as to how to prevent this state latch up from occurring, other than to reset the entire ISP when it occurs, which seems a little crude. Any further ideas or tips as to where I should be looking would be appreciated. Many Thanks Adam -- 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: Omap3 ISP + Gstreamer v4l2src
Hi Laurent, Michael, Please note that BT.656 support is still experimental, so issues are not unexpected. Yes, I was aware that this is not yet fully baked. My question is, should this "just work"? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a "standard V4L2 device node" is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. Here was my submission for ENUM_FMT support: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html I submitted this in order to be able to use the omap3-isp with GStreamer. I missed the discussion about V4L2 "profiles", but when I submitted that patch we discussed whether ENUM_FMT was mandatory. After I pointed out that the V4L2 spec states plainly that it _is_ mandatory, I thought Laurent basically agreed that it was reasonable. Laurent, what do you think about adding ENUM_FMT support now? Thank you both for clarifying the current situation regarding omap3isp / MCF (and Michael for the previous patch, which I will take a look at). This addresses quite a few questions that I have been mulling over in the last few days. Best Regards Adam -- 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
Omap3 ISP + Gstreamer v4l2src
Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l '"tvp5150 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' media-ctl -v --set-format '"tvp5150 3-005d":0 [UYVY2X8 720x625]' media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x625]' media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x625]' This yields this: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] <- "OMAP3 ISP CCP2 input":0 [] pad1: Source [SGRBG10 4096x4096] -> "OMAP3 ISP CCDC":0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source -> "OMAP3 ISP CCP2":0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] -> "OMAP3 ISP CSI2a output":0 [] -> "OMAP3 ISP CCDC":0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink <- "OMAP3 ISP CSI2a":1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] <- "OMAP3 ISP CCP2":1 [] <- "OMAP3 ISP CSI2a":1 [] <- "tvp5150 3-005d":0 [ENABLED] pad1: Source [UYVY2X8 720x625] -> "OMAP3 ISP CCDC output":0 [ENABLED] -> "OMAP3 ISP resizer":0 [] pad2: Source [UYVY2X8 720x624] -> "OMAP3 ISP preview":0 [] -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink <- "OMAP3 ISP CCDC":1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] <- "OMAP3 ISP CCDC":2 [] <- "OMAP3 ISP preview input":0 [] pad1: Source [YUYV 4082x4088] -> "OMAP3 ISP preview output":0 [] -> "OMAP3 ISP resizer":0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source -> "OMAP3 ISP preview":0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Sink <- "OMAP3 ISP preview":1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082] <- "OMAP3 ISP CCDC":1 [] <- "OMAP3 ISP preview":1 [] <- "OMAP3 ISP resizer input":0 [] pad1: Source [YUYV 3312x4095] -> "OMAP3 ISP resizer output":0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Source -> "OMAP3 ISP resizer":0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink <- "OMAP3 ISP resizer":1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Sink <- "OMAP3 ISP CCDC"
Re: Getting started with OMAP3 ISP
On Tue, Sep 6, 2011 at 10:49 AM, Laurent Pinchart wrote: > On Monday 05 September 2011 18:37:04 you wrote: >> Yes that was the first thing i tried, anyway now i have it finally >> working. Well at least yavta doesn't hang, do you know some >> application to see raw yuv images? I made a typo since in fact it's uyvy ( so a tool to covert from yuv will not work ;) ), but if someone will ever need it: ffmpeg -f rawvideo -pix_fmt uyvy422 -s 720x628 -i frame-01.bin frame-1.png Enrico Enrico, Gary, I am in an identical situation to you both in that I am migrating to a newer kernel and am faced with the task of getting a driver for the tvp5150 working with the new MC framework and omap3 ISP. I understand from reading this thread that you have both had some success in modifying an existing / writing a driver and configuring a MC pipeline. If you are able to share your driver(s) or any insights, I would be very grateful and I am happy to help out with further testing or polishing as required. Best Regards Adam -- 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
