ispvideo patch
Laurent,
Attached is a patch that enables purely V4L2 applications to work if the
media pipeline has been previously setup using media-ctl.
I have tested it with both ffmpeg and gstreamer.
It works by querying the linked subdev's format when the ispvideo device
is opened. If there is no linked subdev, it behaves as it did previously.
Lane
diff --git a/drivers/media/video/isp/ispvideo.c
b/drivers/media/video/isp/ispvideo.c
index 1edfafa..0e37062 100644
--- a/drivers/media/video/isp/ispvideo.c
+++ b/drivers/media/video/isp/ispvideo.c
@@ -988,6 +988,69 @@ isp_video_s_input(struct file *file, void *fh, unsigned
int input)
return input == 0 ? 0 : -EINVAL;
}
+static int
+isp_video_enum_format(struct file *file, void *fh, struct v4l2_fmtdesc *f)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ if (f-index 0 || f-type != video-type)
+ return -EINVAL;
+
+ mutex_lock(video-mutex);
+ f-flags = 0;
+ f-pixelformat = vfh-format.fmt.pix.pixelformat;
+ mutex_unlock(video-mutex);
+ return 0;
+}
+
+static int
+isp_video_enum_framesizes(struct file *file, void *fh,
+ struct v4l2_frmsizeenum *f)
+{
+ int ret = 0;
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ if (f-index 0)
+ return -EINVAL;
+
+ mutex_lock(video-mutex);
+ if (f-pixel_format == vfh-format.fmt.pix.pixelformat) {
+ f-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ f-discrete.width = vfh-format.fmt.pix.width;
+ f-discrete.height = vfh-format.fmt.pix.height;
+ } else {
+ ret = -EINVAL;
+ }
+ mutex_unlock(video-mutex);
+ return 0;
+}
+
+static int
+isp_video_enum_ivals(struct file *file, void *fh, struct v4l2_frmivalenum *f)
+{
+ int ret = 0;
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ if (f-index 0)
+ return -EINVAL;
+
+ mutex_lock(video-mutex);
+ if (f-pixel_format == vfh-format.fmt.pix.pixelformat
+ f-width== vfh-format.fmt.pix.width
+ f-height == vfh-format.fmt.pix.height) {
+ f-type = V4L2_FRMIVAL_TYPE_DISCRETE;
+ f-discrete.numerator = vfh-timeperframe.numerator;
+ f-discrete.denominator = vfh-timeperframe.denominator;
+ } else {
+ ret = -EINVAL;
+ }
+ mutex_unlock(video-mutex);
+ return ret;
+}
+
static const struct v4l2_ioctl_ops isp_video_ioctl_ops = {
.vidioc_querycap= isp_video_querycap,
.vidioc_g_fmt_vid_cap = isp_video_get_format,
@@ -1010,16 +1073,57 @@ static const struct v4l2_ioctl_ops isp_video_ioctl_ops
= {
.vidioc_enum_input = isp_video_enum_input,
.vidioc_g_input = isp_video_g_input,
.vidioc_s_input = isp_video_s_input,
+ .vidioc_enum_fmt_vid_cap= isp_video_enum_format,
+ .vidioc_enum_frameintervals = isp_video_enum_ivals,
+ .vidioc_enum_framesizes = isp_video_enum_framesizes,
};
/*
-
* V4L2 file operations
*/
+static int __find_timeperframe(struct media_entity_pad *pad,
+ struct v4l2_subdev *subdev,
+ struct v4l2_subdev_frame_interval *fi,
+ int depth) {
+ int err;
+ unsigned int i;
+ if (depth 16) /* max depth. if this depth reached, bail the search. */
+ return -EINVAL;
+
+ err = v4l2_subdev_call(subdev, video, g_frame_interval, fi);
+ if (err 0) {
+ /* Trace backwards through the pipeline to find a subdev
+ with the frame interval set. */
+ struct media_entity_pad *_pad;
+ struct v4l2_subdev *_subdev;
+ for (i = 0; i pad-entity-num_pads; ++i) {
+ _pad = pad-entity-pads + i;
+ if (i == pad-index ||
+ _pad-type != MEDIA_PAD_TYPE_INPUT)
+ continue;
+ _pad = media_entity_remote_pad(_pad);
+ if (!_pad ||
+ _pad-entity-type != MEDIA_ENTITY_TYPE_SUBDEV)
+ continue;
+ _subdev = media_entity_to_v4l2_subdev(_pad-entity);
+ err = __find_timeperframe(_pad, _subdev, fi, depth+1);
+ if (err 0)
+ continue;
+ else
+ return err;
+ }
+ return -EINVAL; /* search failed to find any frame
Re: Translation Faults on OMAP ISP update
On 12/02/2010 07:35 AM, Laurent Pinchart wrote: [snip] Any ideas on the problem? Is there a way to force a reset to the CCDC so that it will become IDLE? Would you expect the ISP to recover gracefully if you removed the OMAP3530 or the RAM from the board and plugged it back ? The same applies to the sensor :-) Long story short, once started, the CCDC can't be stopped before the end of the image. When you unplug the sensor the CCDC will wait forever for the end of frame. When restarted it will resume working to the previous, no longer mapped buffer, leading to IOMMU faults. The CCDC, like most ISP blocks, can't be reset individually. You need to reset the whole ISP to recover from this (blame whoever decided that individual block resets were not useful). This was done before on streamoff, but now that the ISP driver supports running multiple pipelines in parallel we can't do it anymore. It might be possible to write a clean patch to reset the ISP when all streams are stopped. In the meantime you can rmmod/modprobe the driver. Laurent, Thanks for the feedback. The behavior makes perfect sense now. I can take it from here. Given the user *can* unplug the sensor module in our hardware, I need to do something, as locking up the kernel is not acceptable. I will first look to see if an ISP reset on stream off works, as we can sacrifice multiple pipeline support (for now). Lane -- 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
Translation Faults on OMAP ISP update
Laurent, Previously I was getting iommu translation faults when switching from the RESIZER output to the CCDC output. I have finally pulled in all the changes on the git://gitorious.org/maemo-multimedia/omap3isp-rx51.git line and I am happy to say that those translation faults have gone away. I can now switch between the RESIZE and the CCDC without any issues. I still have a problem though. Our image sensor plugs in as a module and can unfortunately be unplugged while the pipeline is streaming. When this happens, I get a select timeout (as I would expect) and then when I stop the stream I get the message: omap3isp omap3isp: CCDC stop timeout! omap3isp omap3isp: Unable to stop OMAP3 ISP CCDC When I plug the image sensor module back in, I can open the devices back up and setup the pipeline without issue, but when I try to start the stream back up, I get: omap-iommu omap-iommu.0: omap2_iommu_fault_isr: da:004b4600 translation fault omap-iommu omap-iommu.0: iommu_fault_handler: da:004b4600 pgd:ce348010 *pgd:8d3b8c01 pte:cd3b8ed0 *pte:885e0002 omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX and the kernel locks up hard. This translation fault, the GFX_FIFO_UNDERFLOW, and kernel locking up are new behavior. Previously I would just get CCDC won't become idle error message when I tried to start the stream back up. Any ideas on the problem? Is there a way to force a reset to the CCDC so that it will become IDLE? Lane -- 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
Media framework backwards compatibility
Laurent, Things in general are working with our camera implementation using the OMAP ISP module. There is, however, a lingering issue that I now need to work out regarding the fact that most user space applications do not work with our camera because of the new media framework. Currently, the only way we have to use our camera is through a custom user space application we wrote (that makes heavy use of the media-ctl user space application for setting up the media links). What I am hoping for, though, is the ability to setup the media links from the media-ctl application and then have a typical V4L2 user space application use the OMAP ISP resizer output device node as usual. Here is what I would like to do: 1. Setup the links to the resizer using a command line app (like media-ctl). 2. Point a typical V4L2 application (like gstreamer or ffmpeg) to read from the resizer output device node and have it negotiate the format using traditional V4L2 ioctls (VIDIOC_G_FMT/VIDIOC_S_FMT). If the links are setup to the resizer, then it seems that user space applications should be able to talk the resizer output (/dev/video3) like a traditional V4L2 device and need not worry about the new media framework. It even seems possible for the resizer to allow the final link format to be adjusted so that the user space application can actually adjust the resizer subdev output format across the range of valid resizer options based on the format of the resizer input pad. If the resizer output device node worked this way, then our camera would work with all the existing V4L2 applications with the simple caveat that the user has to run a separate setup application first. The resizer output device node does not currently behave this way, and I am not sure why. These are the reasons that I can think of as to why: 1. It has not been implemented this way yet. 2. I am doing something incorrectly with the media-ctl application. 3. It not intended to work this way (by the new media framework design principles). 4. It cannot work this way because of some reason I am not considering. I haven't looked at the resizer code yet, but if the answer is 1, then I will take a look at implementing it as I described. Otherwise, let me know. Thanks, Lane -- 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 framework backwards compatibility
Laurent, Thanks for the quick feedback. See my comments below: On 11/23/2010 04:45 PM, Laurent Pinchart wrote: On Tuesday 23 November 2010 23:29:10 Lane Brooks wrote:Laurent, If the links are setup to the resizer, then it seems that user space applications should be able to talk the resizer output (/dev/video3) like a traditional V4L2 device and need not worry about the new media framework. It even seems possible for the resizer to allow the final link format to be adjusted so that the user space application can actually adjust the resizer subdev output format across the range of valid resizer options based on the format of the resizer input pad. If the resizer output device node worked this way, then our camera would work with all the existing V4L2 applications with the simple caveat that the user has to run a separate setup application first. The resizer output device node does not currently behave this way, and I am not sure why. These are the reasons that I can think of as to why: 1. It has not been implemented this way yet. 2. I am doing something incorrectly with the media-ctl application. 3. It not intended to work this way (by the new media framework design principles). 4. It cannot work this way because of some reason I am not considering. It's probably a combination of 1 and it cannot work this way because of reasons I can't remember at 1AM :-) The ISP video device nodes implementation doesn't initialize vfh-format when the device node is opened. I think this should be fixed by querying to connected subdevice for its current format. Of course there could be no connected subdevice when the video device node is opened, in which case the format can't be initialized. Pure V4L2 applications must not try to use the video device nodes before the pipeline is initialized. I'll look into implementing this. This is mostly what I am looking for and hopefully won't be too involved to implement. Regarding adjusting the format at the output of the connected subdevice when the video device node format is set, that might be possible to implement, but we will run into several issues. One of them is that applications currently can open the video device nodes, set the format and request buffers without influencing the ISP at all. The format set on the video device node will be checked against the format on the connected pad at streamon time. This allows preallocating buffers for snapshot capture to lower snapshot latency. Making set_format configure the connected subdev directly would break this How does calling set_format on the subdev pad at the same as the device node prevent preallocating buffers? I don't really understand the ISP buffering, so I think at this point I will look into implementing the previous option and then perhaps I will have a better understanding of the issue you raise here. I think it is only the resizer that would need this capability. I am bringing it up as a nice to have, but we can certainly live without it if it does not fit into the design goals of the framework. Lane -- 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: Translation faults with OMAP ISP
On 11/19/2010 06:29 AM, David Cohen wrote: On Thu, Nov 18, 2010 at 12:17:21AM +0100, ext Lane Brooks wrote: On Wednesday 17 November 2010 00:46:27 Lane Brooks wrote: Laurent, I am getting iommu translation errors when I try to use the CCDC output after using the Resizer output. If I use the CCDC output to stream some video, then close it down, switch to the Resizer output and open it up and try to stream, I get the following errors spewing out: omap-iommu omap-iommu.0: omap2_iommu_fault_isr: da:00d0ef00 translation fault omap-iommu omap-iommu.0: iommu_fault_handler: da:00d0ef00 pgd:ce664034 *pgd: and the select times out. From a fresh boot, I can stream just fine from the Resizer and then switch to the CCDC output just fine. It is only when I go from the CCDC to the Resizer that I get this problem. Furthermore, when it gets into this state, then anything dev node I try to use has the translation errors and the only way to recover is to reboot. Any ideas on the problem? I'm not sure if it's your case, but OMAP3 ISP driver does not support pipeline with multiples outputs yet. We have to return error from the driver in this case. If you configured CCDC to write to memory and then to write to preview/resizer afterwards without deactivating the link to write to memory, you may face a similar problem you described. Can you please try a patch I've sent to you (CC'ing linux-media) with subject: [omap3isp][PATCH] omap3isp: does not allow pipeline with multiple video outputs yet? Regards, David David, I am not trying to use multiple outputs simultaneously. I get the translation error with the following sequence: - Open resizer output and setup media links. - Stream some images. - Close resizer. - Reset all media links. - Open CCDC and setup media links. - Try to stream some images but get translation faults. Is your patch going to help with this problem? Lane -- 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: Translation faults with OMAP ISP
On 11/19/2010 07:13 AM, Laurent Pinchart wrote: On Friday 19 November 2010 15:08:38 Lane Brooks wrote: On 11/19/2010 06:29 AM, David Cohen wrote: On Thu, Nov 18, 2010 at 12:17:21AM +0100, ext Lane Brooks wrote: On Wednesday 17 November 2010 00:46:27 Lane Brooks wrote: Laurent, I am getting iommu translation errors when I try to use the CCDC output after using the Resizer output. If I use the CCDC output to stream some video, then close it down, switch to the Resizer output and open it up and try to stream, I get the following errors spewing out: omap-iommu omap-iommu.0: omap2_iommu_fault_isr: da:00d0ef00 translation fault omap-iommu omap-iommu.0: iommu_fault_handler: da:00d0ef00 pgd:ce664034 *pgd: and the select times out. From a fresh boot, I can stream just fine from the Resizer and then switch to the CCDC output just fine. It is only when I go from the CCDC to the Resizer that I get this problem. Furthermore, when it gets into this state, then anything dev node I try to use has the translation errors and the only way to recover is to reboot. Any ideas on the problem? I'm not sure if it's your case, but OMAP3 ISP driver does not support pipeline with multiples outputs yet. We have to return error from the driver in this case. If you configured CCDC to write to memory and then to write to preview/resizer afterwards without deactivating the link to write to memory, you may face a similar problem you described. Can you please try a patch I've sent to you (CC'ing linux-media) with subject: [omap3isp][PATCH] omap3isp: does not allow pipeline with multiple video outputs yet? Regards, David David, I am not trying to use multiple outputs simultaneously. I get the translation error with the following sequence: - Open resizer output and setup media links. - Stream some images. - Close resizer. - Reset all media links. - Open CCDC and setup media links. - Try to stream some images but get translation faults. Is your patch going to help with this problem? If you reset all links before setting them up for the CCDC output, probably not (unless you have a bug in your CCDC links setup, but I doubt that). I can stream just fine from the CCDC output if I do not use the resizer prior, so I am pretty sure I am setting up the CCDC links correctly. -- 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: Translation faults with OMAP ISP
On 11/17/2010 04:09 PM, Laurent Pinchart wrote: Hi Lane, On Wednesday 17 November 2010 00:46:27 Lane Brooks wrote: Laurent, I am getting iommu translation errors when I try to use the CCDC output after using the Resizer output. If I use the CCDC output to stream some video, then close it down, switch to the Resizer output and open it up and try to stream, I get the following errors spewing out: omap-iommu omap-iommu.0: omap2_iommu_fault_isr: da:00d0ef00 translation fault omap-iommu omap-iommu.0: iommu_fault_handler: da:00d0ef00 pgd:ce664034 *pgd: and the select times out. From a fresh boot, I can stream just fine from the Resizer and then switch to the CCDC output just fine. It is only when I go from the CCDC to the Resizer that I get this problem. Furthermore, when it gets into this state, then anything dev node I try to use has the translation errors and the only way to recover is to reboot. Any ideas on the problem? Ouch. First of all, could you please make sure you run the latest code ? Many bugs have been fixed in the last few months I had a pretty good idea that this would be your response, but I was hoping otherwise as merging has become more and more difficult to keep up with. Anyway, until I have a chance to merge in everything, I just found a work around for our usage needs, and that is to always use the resizer output and just change the resizer format between full resolution and preview resolution. This has turned out to be much more stable than switching between the CCDC and RESIZER dev nodes. Thanks again for your feedback. Lane -- 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
Translation faults with OMAP ISP
Laurent, I am getting iommu translation errors when I try to use the CCDC output after using the Resizer output. If I use the CCDC output to stream some video, then close it down, switch to the Resizer output and open it up and try to stream, I get the following errors spewing out: omap-iommu omap-iommu.0: omap2_iommu_fault_isr: da:00d0ef00 translation fault omap-iommu omap-iommu.0: iommu_fault_handler: da:00d0ef00 pgd:ce664034 *pgd: and the select times out. From a fresh boot, I can stream just fine from the Resizer and then switch to the CCDC output just fine. It is only when I go from the CCDC to the Resizer that I get this problem. Furthermore, when it gets into this state, then anything dev node I try to use has the translation errors and the only way to recover is to reboot. Any ideas on the problem? Thanks, Lane -- 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
Snapshot with the OMAP
Laurent, Suppose I am streaming 2048x1536 YUV images from a sensor into the OMAP. I am piping it through the resizer to drop it to 640x480 for display. So I am reading from /dev/video6 (resizer) and have the media bus links setup appropriately. Now the user presses the shutter button. What is the recommended way to read a single full resolution image? It seems there are several options: 1. Reconfigure the media bus and read a single single full resolution image out of the CCDC output on /dev/video2 and then reconfigure it back to video mode. 2. Reconfigure the resizer to stop downsampling but instead output the full resolution image for a single frame. Do I need to stop the stream while doing either option? These seem like clunky and slow options, though. Is there a way to setup the media bus links so that I can actually have handles to /dev/video2 and /dev/video6 open simultaneously? Then I can normally read from /dev/video6 and then read single frames from /dev/video2 whenever the user presses the shutter button? I have noticed there is a some ISP_PIPELINE_STREAM_SINGLESHOT streaming states in the isp code, but I don't what it is for or how to use it. Is it related to my questions at all? It gets even more complex if I want the streaming the video out of the sensor at a lower resolution (for higher video rates) and want to change the resolution of the sensor for the snapshot. Thanks, Lane -- 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
OMAP ISP and Overlay
Laurent, So far I have the everything working with the OMAP ISP to where I can stream video on our custom board. On a previous generation of hardware with a completely different processor and sensor, we used the V4L2 overlay feature to stream directly to our LCD for preview. I am wondering what the plans are for overlay support in the omap ISP? How does the overlay feature fit into the new media bus feature? Thanks, Lane -- 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 Bridge Problems
On 08/09/2010 03:25 AM, Laurent Pinchart wrote: Hi Lane, On Monday 09 August 2010 00:56:27 Lane Brooks wrote: On 08/08/2010 04:29 PM, Laurent Pinchart wrote: Hi Lane, Thanks for the patch. On Thursday 05 August 2010 20:53:50 Lane Brooks wrote: [snip] I was able to get YUV CCDC capture mode working with rather minimal effort. Attached is a patch with the initial effort. Can you comment? Writing to the ISPCCDC_SYN_MODE register should be moved to ccdc_configure(). Just move the switch statement there right after the format =ccdc-formats[CCDC_PAD_SINK]; line (without the ispctrl_val settings), it should be enough. + isp_reg_writel(isp, ispctrl_val, OMAP3_ISP_IOMEM_MAIN, + ISP_CTRL); The ISP_CTRL register should be written in isp_select_bridge_input() only. As you correctly mention, whether the data is in little endian or big endian format should come from platform data, so I think it's fine to force board files to set the isp-pdata-parallel.bridge field to the correct value. Putting the bridge settings in the platform data is tricky because they need to change depending on the selected format. For example, for my board, when in SGRBG mode, the bridge needs disabled. When in YUV16 mode, however, I need need to select BIG/LITTLE endian depending on whether it is YUYV or UYVY or ... Ah right... So your sensor can output both Bayer and YUV data ? What sensor is that BTW ? Aptina MT9T111. It can even output JPEG. I am not quite sure how to capture that in the platform data without enumerating every supported format code in the platform data. The current patch knows (based on the OMAP TRM) that YUV16 mode requires the bridge to be enabled. So in the platform data I specify the bridge state for SGBRG mode and force the bridge to BIG endian in YUV16 mode. This leaves the sensor to switch the phasing based on YUYV, YVYU, etc. mode. I am not sure who should be in charge of doing byte swapping in general, but if the input and output modes are the same, then big endian should be used to avoid a byte swap. In other words, the mode is completely determinable based on the formats, so perhaps I should implement it that way. If the input and output port require a byte swap, then go little endian, otherwise go big endian. OK I understand. The best solution (for now) would then be to modify isp_configure_bridge(). I wrote a few patches that modify how platform data is handled, but I can't commit them at the moment (they depend on other patches that I still need to clean up). The reason why I put both writes to the ISPCTRL and SYN_MODE registers where I did. Moving them to other places will require querying the selected format code. Is that what you want as well? For SYN_MODE, definitely. For ISPCTRL, you can hack isp_configure_bridge() to retrieve the current CCDC input format, and we'll write a proper fix right after I commit my platform data restructuring patches. I'll wait for your patches then. Let me know. -- 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 Bridge Problems
On 08/08/2010 04:13 PM, Laurent Pinchart wrote:
Hi Lane,
On Thursday 05 August 2010 18:06:51 Lane Brooks wrote:
On 08/04/2010 02:57 PM, Laurent Pinchart wrote:
On Tuesday 03 August 2010 17:26:48 Lane Brooks wrote:
[snip]
My question:
- Are there other things I need to when I enable the parallel bridge?
For example, do I need to change a clock rate somewhere? From the TRM,
it seems like it should just work without any changes, but maybe I am
missing something.
Good question. ISP bridge and YUV modes support are not implemented in
the driver, but you're probably already aware of that.
I unfortunately have no straightforward answer. Try tracing the ISP
interrupts and monitoring the CCDC SBL busy bits to see if the CCDC
writes images to memory correctly.
I found at least some of the problem. In my platform data I was enabling
the bridge using the #defines in ispreg.h as in
static struct isp_platform_data bmi_isp_platform_data = {
.parallel = {
.data_lane_shift= 3,
.clk_pol= 0,
.bridge = ISPCTRL_PAR_BRIDGE_LENDIAN,
},
.subdevs = bmi_camera_subdevs,
};
The bridge related #defines in ispreg.h, however, have a shift of 2
applied to them. The problem is that the shift is applied again in isp.c
when the options are actually applied. In other words, the bridge
parameters are being shifted up twice, which is causing corruption to
the control register and causing my hanging problems when I try to
enable the bridge. It seems there are several other such cases in the
ispreg.h where double shifting might occur if the user tries to use them
in the platform data.
My question:
Is this an oversight or is it this way on purpose? Am I not supposed to
be using these defines in my platform definitions? It seems that *some*
of the parameters in ispreg.h should not be shifted up (like the bridge
options).
It's a bug, thanks for pointing it out. The value shouldn't be shifted again
in isp_select_bridge_input(). Do you want to submit a patch ?
The isp_parallel_platform_data struct specifies the bridge definition as
2 bits, so if the shift is removed from isp_select_bridge instead of
from the ispreg.h file, then the platform_data definition needs modified
as well. Is that what you want?
--
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 Bridge Problems
On 08/08/2010 04:29 PM, Laurent Pinchart wrote: Hi Lane, Thanks for the patch. On Thursday 05 August 2010 20:53:50 Lane Brooks wrote: [snip] I was able to get YUV CCDC capture mode working with rather minimal effort. Attached is a patch with the initial effort. Can you comment? Writing to the ISPCCDC_SYN_MODE register should be moved to ccdc_configure(). Just move the switch statement there right after the format =ccdc-formats[CCDC_PAD_SINK]; line (without the ispctrl_val settings), it should be enough. + isp_reg_writel(isp, ispctrl_val, OMAP3_ISP_IOMEM_MAIN, + ISP_CTRL); The ISP_CTRL register should be written in isp_select_bridge_input() only. As you correctly mention, whether the data is in little endian or big endian format should come from platform data, so I think it's fine to force board files to set the isp-pdata-parallel.bridge field to the correct value. Putting the bridge settings in the platform data is tricky because they need to change depending on the selected format. For example, for my board, when in SGRBG mode, the bridge needs disabled. When in YUV16 mode, however, I need need to select BIG/LITTLE endian depending on whether it is YUYV or UYVY or ... I am not quite sure how to capture that in the platform data without enumerating every supported format code in the platform data. The current patch knows (based on the OMAP TRM) that YUV16 mode requires the bridge to be enabled. So in the platform data I specify the bridge state for SGBRG mode and force the bridge to BIG endian in YUV16 mode. This leaves the sensor to switch the phasing based on YUYV, YVYU, etc. mode. I am not sure who should be in charge of doing byte swapping in general, but if the input and output modes are the same, then big endian should be used to avoid a byte swap. In other words, the mode is completely determinable based on the formats, so perhaps I should implement it that way. If the input and output port require a byte swap, then go little endian, otherwise go big endian. The reason why I put both writes to the ISPCTRL and SYN_MODE registers where I did. Moving them to other places will require querying the selected format code. Is that what you want as well? Lane -- 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
