Re: [RFC] v4l: omap4iss: DT bindings development

[Tony Lindgren <tony@atomide.com>]

* Michael Allwright <michael.allwright@upb.de> [150602 01:41]:
> Hi Everyone,
> 
> I'm working on the DT bindings for the OMAP4 ISS at the moment, but I
> am unable to capture any data in my test setup. As detailed below, it
> seems that everything has been configured correctly however I never
> get any interrupts from the ISS unless I do something drastic like
> removing one of the wires from the clock differential pair which
> results in constant complex IO error interrupts from CSIA until I
> restore the physical connection.
> 
> My test setup includes a OV6540 sensor camera module (MIPI) from
> Lepoard Imaging, an Duovero COM from Gumstix and breakout boards
> forming an interconnect between the two. The sensor is connected to
> CSI21 on the OMAP4 using a clock lane (on position 1, default
> polarity) and a single data lane (on position 2, default polarity),
> the sensor input clock XVCLK uses the OMAP4 auxclk1_ck channel (rounds
> to 19.2MHz when asked for 24MHz).
> 
> The relevant parts of my device tree can be seen here:
> https://gist.github.com/allsey87/fdf1feb6eb6a94158638 - I'm actually
> somewhat unclear what effect stating the ti,hwmod="iss" parameter has.
> Does anything else need to be done here? As far as I can tell I think
> all clocks and power has been switched on. I do make two function
> calls to the PM API in the ISS probe function, i.e.:
> 
> pm_runtime_enable(&pdev->dev);
> r = pm_runtime_get_sync(&pdev->dev);

The ti,hwmod = "iss" hooks up the device with the PM runtime, see
omap_hwmod_44xx_data.c for "iss".
 
> Regarding my debugging, this is what I have checked so far
> 
> * Changing the pixel rate of the sensor - this lead me to discover a
> possible bug in iss.c or perhaps my ov5640 driver, as the
> V4L2_CID_PIXEL_RATE control was always returning zero. I patched this
> by copying what Laurent has done in the OMAP3ISP driver which now
> works.
> * As I only have a 100MHz scope, I had to slow down the camera
> significantly (MIPI clock => 10-12MHz range) to verify that I was
> getting reasonable output from the sensor (i.e. signals that were
> characteristic of CSI2/MIPI). I checked the calculations and made sure
> these updated values came across via the V4L2_CID_PIXEL_RATE control
> and ended up in the THS_TERM and THS_SETTLE fields of register 0.
> * Using the omapconf tool, I have manually and one by one pulled up
> the CSI2 pins and verified multiple times all connections to the
> sensor module and have even manually tried swapping the DP/DN pairs in
> case they were still somehow backwards despite previous testing
> * Verified that the interrupt service routine is called by generating
> a test interrupt HS_VS from inside the ISS i.e.
> 
> ./omapconf write ISS_HL_IRQENABLE_SET_5 0x00020000
> ./omapconf write ISS_HL_IRQSTATUS_RAW_5 0x00020000
> 
> * Verified that the default CMA region is being used, it ends up in
> the ping-pong resisters of the ISS.
> 
> Additional information:
> 
> * Initialisation of pipe line and stream commands:
> 
> media-ctl -r -l '"OMAP4 ISS CSI2a":1 -> "OMAP4 ISS CSI2a output":0 [1]'
> media-ctl -V '"ov5640 2-003c":0 [UYVY 640x480]','"OMAP4 ISS CSI2a":0
> [UYVY 640x480]'
> yavta /dev/video0 -c4 -n1 -s640x480 -fUYVY -Fov5640-640x480-#.uyvy
> 
> * Output from OMAPCONF tool is in the second part of:
> https://gist.github.com/allsey87/fdf1feb6eb6a94158638
> 
> Anyway, at this point, I'm almost completely out of ideas on how to
> move forwards so any suggestions, criticisms or help of any nature
> would be appreciated!

Usually it's pinmuxing or some regulator or clock not enabled. Or
incorrect hwmod sysc and syss configuration for iss that prevents
enabling it properly.

Regards,

Tony