Re: OMAP3 Bridge Problems

[Lane Brooks <lane@brooks.nu>]

  On 08/04/2010 02:57 PM, Laurent Pinchart wrote:
> Hi Lane,
>
> 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).

Thanks,
Lane