[Letux-kernel] ov9655 madness in 4.20

Andreas Kemnade andreas at kemnade.info
Wed Jan 9 18:15:51 CET 2019


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.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20190109/a986cfe3/attachment-0001.asc>


More information about the Letux-kernel mailing list