On Tuesday 02 June 2015 09:12:25 Tony Lindgren wrote: > * Michael Allwright <michael.allwright@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
