[Letux-kernel] ov9655 madness in 4.20

H. Nikolaus Schaller hns at goldelico.com
Wed Jan 9 18:25:27 CET 2019


> Am 09.01.2019 um 18:15 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Wed, 9 Jan 2019 17:40:01 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi Andreas,
>> 
>>> Am 09.01.2019 um 11:07 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> 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.
>> 
>> Now I started to test letux-5.0-rc1 and had just booted a gta04a4 with
>> camera. So it was just some key clicks to type camera-demo.
>> 
>> Result was a green image - on first attempt. And some kernel issues ending
>> in a kernel panic :(
>> 
>> Also intersting is "omap3isp 480bc000.isp: CCDC won't become idle!".
>> 
>> Maybe there are some fixes from -rc2 missing...
>> 
>> BTW: this seems to be an old bug: https://www.isee.biz/support/ccdc-won-t-become-idle
>> https://e2e.ti.com/support/processors/f/791/t/236405?DM3730-CCDC-won-t-become-idle-
>> https://www.spinics.net/lists/linux-media/msg67894.html
>> 
>> The error itself comes from here:
>> 
>> https://elixir.bootlin.com/linux/v5.0-rc1/source/drivers/media/platform/omap3isp/ispccdc.c#L1605
>> 
>> Since CCDC is inside the omap3isp [http://omappedia.org/wiki/Camera-ISP_Driver]
>> we may have some picture format issue...
>> 
>> Finally some other idea:
>> 
>> https://linuxtv.org/downloads/v4l-dvb-apis/v4l-drivers/omap3isp.html
>> 
>> Chapter 20.4 indicates that there are Vertical sync frame events sent around.
>> Maybe we can simply printk the V4L2_EVENT_FRAME_SYNC and see if it starts/stops.
>> It might also indicate wrong VSYNC polarity (although I have checked at least
>> 10 times...).
>> 
>> BR,
>> Nikolaus
>> 
>> 
>> [   99.650756] Address Hole seen by CAM  at address 40000000
> 
> 
> This thing comes from my patch. No idea why... Maybe I really should
> send it upstream as an RFC patch with some more comments. Maybe that
> leads to interesting feedback.

Yes, please do. I think we can learn a lot by getting answers.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190109/794a28c7/attachment.asc>


More information about the Letux-kernel mailing list