[Letux-kernel] ov9655 madness in 4.20

[H. Nikolaus Schaller]

Hi,

> Am 08.01.2019 um 22:12 schrieb Andreas Kemnade <andreas at kemnade.info>:
>> 
> I wrote a dumping tool using /dev/mem.
> 
> Some interesting results I have found now.
> Clock/Vsync polarity changes between 3.7 and 4.20. That might explain
> the green border in 3.7.

Yes, I remember this was fixed for 3.12 (and maybe other things in
the camera driver).

> 
> Accessibility of registers:
>  3.7 when camera is active
>  4.20 without iommu patch: when the module is loaded
>  4.20 with iommu patch: only if there is activity (matches behavior
>       of other devices)
> 
> No idea why this iommu patch has that effect especially since
> the iommu calls look the same as in 3.7.
> 
> Dump diff between first and second camera demo run on 4.20:
> 
> --- isp-4.20-mplayer-1	2000-01-01 01:08:05.000000000 +0100
> +++ isp-4.20-mplayer-2	2000-01-01 01:09:41.000000000 +0100
> @@ -262,7 +262,7 @@
> 
> ISP_CCDC
> 480bc600 (0000): 0001fe01
> -480bc604 (0004): 00000000
> +480bc604 (0004): 00000001

^^^ CCDC

> 480bc608 (0008): 00031704
> 480bc60c (000c): 00000000
> 480bc610 (0010): 00000000
> @@ -272,7 +272,7 @@
> 480bc620 (0020): ffff00ff
> 480bc624 (0024): 00000a00
> 480bc628 (0028): 00000000
> -480bc62c (002c): 40300000
> +480bc62c (002c): 40000000

^^^ CCDC_SDR_ADDR

Memory address
Sets the CCDC module output address. The address should be aligned on a 32-byte boundary: the 5 least significant bits are ignored.
For optimal performance in the system, the address must be on a 256-byte boundary.
This bit field is latched by the VS sync pulse.

This seems to depend on memory assignment by the driver.

> 480bc630 (0030): 00000010
> 480bc634 (0034): 00000000
> 480bc638 (0038): bb11bb11
> @@ -403,8 +403,8 @@
> 480bca24 (0024): 00000000
> 480bca28 (0028): 00000000
> 480bca2c (002c): 00000000
> -480bca30 (0030): 00000000
> -480bca34 (0034): 000d0db2
> +480bca30 (0030): 00000002
> +480bca34 (0034): 000eaee9

^^^ HIST_ADDR and HIST_DATA

IMHO not relevant to the issue.

> 480bca38 (0038): 00000000
> 480bca3c (003c): 00000000
> 480bca40 (0040): 00000000
> @@ -921,10 +921,10 @@
> 480bd21c (001c): 00000098
> 480bd220 (0020): 00000118
> 480bd224 (0024): 00000198
> -480bd228 (0028): 00040529
> -480bd22c (002c): 00040529
> -480bd230 (0030): 00040529
> -480bd234 (0034): 00040529
> +480bd228 (0028): 0004057f
> +480bd22c (002c): 0004057f
> +480bd230 (0030): 0004057f
> +480bd234 (0034): 0004057f

^^^ SBL_CCDC_WR_0 .. SBL_CCDC_WR_3

CCDC WRITE REQUEST 1 REGISTER

contains "Upper 20 bits of the write address."

So this change may also just depend on memory assignment by the driver.

> 480bd238 (0038): 00000000
> 480bd23c (003c): 00000000
> 480bd240 (0040): 00000000
> 
> 
> 
>>> Hmm, then we have the iommu. Not sure if there might happen something
>>> interesting.
>>> 
>>> And i2c access comparison. But I guess that is already boiled.  
>> 
>> Yes, I had checked register values with 3.12. So it is not a problem
>> of the camera module. It *might* be something missing in the driver
>> not properly calling some core V4L2 functions, but I have compared
>> several times with other drivers.
>> 
>> It might also be something that clock is not properly stopped and
>> re-enabled between two attempts.
>> 
>> But the omap3isp and its driver is a complex beast... And that the
>> select() does timeout is when V4L2 tries to read a video stream from
>> the isp (not the camera). I.e. there is no data coming from isp.
>> 
> That leaves still the question whether the isp delivers no date because
> it gets nothing from the camera. Well, since the camera gets its clock
> so that we can access it via i2c, I doubt that the problem is on camera
> side.

I tend to agree... And AFAIR, there is no I2C possible if there is no
clock. Other chips have a stand-alone I2C engine without external clock,
but the camera module seems to need it.

BR,
Nikolaus