[Letux-kernel] ov9655 madness in 4.20

Andreas Kemnade andreas at kemnade.info
Tue Jan 8 22:12:10 CET 2019


Hi Nikolaus,

On Tue, 8 Jan 2019 18:11:27 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

> Hi Andreas,
> 
> > Am 08.01.2019 um 17:23 schrieb Andreas Kemnade <andreas at kemnade.info>:
> > 
> > Hi Nikolaus,
> > 
> > On Sat, 5 Jan 2019 20:54:05 +0100
> > "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> >   
> >>>>> So the workaround is easily rmmod both omap3_isp and ov9655
> >>>>> and this is nothing with high priority to fix.  
> >>>> 
> >>>> Well, should it be locked somehow? Other modules seems to be able
> >>>> to describe dependencies and then you can't even rmmod them.
> >>>>   
> >>> ov9650 should either prevent removal of omap3_isp or the ov9650 should
> >>> put() the clock when not in use. No idea what is better.  
> >> 
> >> Probably a put(). The camera driver should know if it needs a clock or not...
> >>   
> >>> But that is low
> >>> priority as long as we do not know how to give the OMAP ISP-hwmod
> >>> the right kick in the a** to start again.  
> >> 
> >> Indeed. This problem made me give up working on the driver many months ago,
> >> because I wasn't able to solve it. So although the plan was to upstream
> >> the driver (there was someone really intersted in it as well), I moved to
> >> other topics (and there are always too many :)
> >>   
> > hmm, we have a working (kernel 3.7 permits to the camera muliple times)  
> 
> letux-3.12 had camera working best...
> 
> > and a non-working system. So we can make some kind of a "diff".
> > Did you diff isp_readl/clr/set/writel calls?  
> 
> No... There was quite some rework in between so that the sequences might
> be completely upside down.
> 
> It is IMHO more interesting to read the register sets through debugfs.
> 
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.

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
 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
 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
 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
 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.

Regards,
Andreas

> BR,
> Nikolaus
> 

-------------- 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/20190108/5aed3dc4/attachment.asc>


More information about the Letux-kernel mailing list