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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote:
> * 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.

And have you tried the same setup with platform data ?

-- 
Regards,

Laurent Pinchart