3.9 regression : CAM_XCLKA wrong frequency setting.

[jean-philippe francois]

2013/5/17 jean-philippe francois <jp.francois at cynove.com>:
> Hi,
>
> Laurent, you are on the recipient list because the symptom is visible
> throug your driver. I found the other name looking in the clock
> related files. Please apologize if you are not concerned by this mail.
>
> Symptom :
> External clock CAM_XCLKA frequency is wrong with 3.9, it was ok until
> 3.6. Everything else is working fine, except the fps are higher, and
> the image quality sucks because the input clock is out of spec.
> Oscilloscope measured freq is around 30 MHz instead of the 24 MHz the
> sensor is asking for.
>
> Hardware :
> dm3730, with 19.2 MHz crystal, running at OPP100
>
> The register frequency settings seems to be ok, and they are the same
> as in 3.6.11 :
> CM_CLKSEL2_PLL : 0x04816807
>         19, 2 * 360 / 8 = 864 MHz
>          this value is already set when I look at it in u-boot
>
> CM_CLKSEL_CAM : 0x5
>         864 / 5 = 172,8 MHz
>         this value is set through the clock framework by the omap3isp
> driver code
>
> ISP.TCTRL_CTRL : 0x7
>         172,8 / 7 = 24,685... MHz
>          this value is set by the omap3isp driver code
>
> However, as stated before, the actual output frequency is NOT 24 MHz
> but around 30.
>
> If dpll4 frequency is wrong, what other clock would be affected ?

As usual, writing a mail brings up new idea. Sorry to use the lists
as rubber duck debug partner, but I still need your help.

Obviously, dpll4 frequency is correct, because it sources the 96 and
48 MHz clock.
I can check it measuring bit time on uart3tx : 8.6usec for 115200 => Ok

30 MHz is 1.25 * 24 MHz
CM_CLKSEL_CAM reset value is 4, programmed value is 5,
So I did the following, while looking at CAM_XCLKA on scope :

# devmem 0x48004f40
0x00000005
# devmem 0x48004f40 32 5  -> freq = 30 MHz
# devmem 0x48004f40 32 4  -> freq = 30 MHz
# devmem 0x48004f40 32 5  -> freq = 24 MHz

So there is something nasty in the setup sequence of cam_mclk and dpll4_m5ckx2
that prevents the new divisor value to be used by the hardware.
I will dive into the code to see where things went wrong, but I am a
bit lost here.

> What can I do to debug this ?
> Laurent, I believe you have a camera add-on board for the beagle xm,
> could you test and report wether you can reproduce this bug ?
>
> Attached is the boot log with 3.9, with some debugging messages activated.
>
> Thank you for your help,
> Regards,
>
> Jean-Philippe François