Hi. >> But documentation on ov9650 is too conflicting and did not cover all >> registers used in driver. > Do you mean the OV9650 datasheet, version 1.3, from September 24, 2004 ? Yes. Also I have datasheet version 1.91 from January 28, 2005 and Application note 1.1 from 7 December 2004 All can be found here [1]. It seems there is different versions of sensor exist. With VER=0x50 and 0x52. I have second one. >>> What resolution are you testing with ? >> >> 320x240. >>> >>> Are you using media-ctl to configure resolution on the camif and sensor >>> subdev ? >> >> I'm using GStreamer: >> gst-launch -v v4l2src device=/dev/video0 \ >> ! video/x-raw-yuv, width=320, height=240 \ >> ! ffmpegcolorspace \ >> ! fbdevsink > > > AFAIR, in the s3c-camif-v3.5 branch there was a bug that the CAMIF input > resolution was not being properly set to what was reported by the sensor > driver (default s3c-camif resolution is 640 x 480). The s3c-camif driver > is supposed to get format from a sensor subdev and set it on the S3C-CAMIF > subdev, upon image sensor subdev registration. Please see function > camif_register_sensor() for details. > > The above issue should be fixed in this branch: > [1] http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif > > Also, it could be verified by setting the formats with media-ctl manually, > before running gst-launch, i.e. > > media-ctl --set-v4l2 '"OV9650":0 [fmt: YUYV2X8/320x240]' > media-ctl --set-v4l2 '"S3C-CAMIF":0 [fmt: YUYV2X8/320x240]' > > with your current kernel and the s3c-camif driver. > media-ctl was integrated in the OSELAS mini2440 BSP and probably is also > in the mini6440 version. Thanks. I'll try it. media-ctl from OpenEmbedded for some reason don't like this params. >>> And what kernel version is it ? >> >> 3.6.0-rc3 with some modifications for mini6410 devboard. Have no time >> to move my stuff to last samsung kernel. > > > OK, it's recent enough. The patches from s3c-camif branch should apply > cleanly. > > >>> Can you measure the frequency of the master clock that CAMIF provides >>> to the sensor ? >> >> 16.67 MHz. As i understand this is limitation of divider. Min clock is >> HCLKx2 (266) / 16 = 16.67 in my case. >> PCLK is near 4 MHz. > > > Looks fine (16.625). > > >>>> :) I spend two days trying to fix it, and now I'm out of ideas. May be >>>> you can help me. >>>> I have some questions. >>>> Did you have to invert some of camera signals (VSYNC, HREF, PCLK)? >>>> Maybe you had to make some hardware modifications? (i use CAM130 >>>> module from FriendlyARM). >>> >>> >>> >>> I'm also using CAM130, attached to mini2440 board without any hardware >>> modifications. Tomasz, (added at Cc) tested the driver on mini6410 and >>> it worked with same camera module. VSYNC, PCLK, etc. configuration is >>> specified in the board patch (as in the below branch). >>> >>> Are you using this version of patches: >>> http://git.linuxtv.org/snawrocki/media.git/shortlog/refs/heads/s3c-camif >>> ? >> >> I'm using patches from >> https://github.com/snawrocki/linux/commits/s3c-camif-v3.5 wich was in >> your mail to samsung maillist. > > > I suggest you to update to the s3c-camif branch as above, it includes some > bug fixes. Sorry, I don't have exact patch for your issue handy right now. I just try this branch. No luck. Now it fails on __ov965x_set_params while writing some registers: ... OV9650: i2c_write: 0x40 : 0xc1. ret: 2 OV9650: i2c_write: 0x29 : 0x3f. ret: 2 OV9650: i2c_write: 0x0F : 0x43. ret: -6 ... If I comment out exits on this errors, following writes in sensors give -6 (ENXIO) or -111 (ECONNREFUSED) erros. Seems sensors hung after write to some registers. >>> I've also added at Cc In-Bae Jeong, who had successfully used the driver >>> on s3c6410 based board. However I'm not really sure now which board >>> exactly >>> was it. >> >> I'm using mini6410. But i think there is only one way sensor can be >> connected to FIMC. Some differents may be in Reset and Power-down >> signals, but not in interface. > > > Yes, right. But since I2C communication works, the GPIOs and the clock > should be fine. It looks like there is a mismatch in the sensor and > the CAMIF registers configuration. > > >> P.S. Try to connect ov2640, but seems it need some modifications in >> FIMC driver to be connected thrue soc_camera_link. > > > Hmm, this is a general problem in the v4l2 core code. The are two slightly > incompatible interfaces that sensor subdevs are using. There were attempts > to make soc_camera subdevs usable with non-soc_camera host drivers, but it > is not finished yet. I could try to look at that, but I can't promise when > that happens. > > There are pad level ops needed in the ov2640 driver - in addition to or > instead of g/s/try_mbus_fmt. Regulator supply names are not supposed to be > passed through platform data, those should be defined with fixed names as > specified in the sensor datasheet and board code should be providing > required > regulator supply names or the dummy regulator should be used. IMO passing > regulator supply names through platform data is the regulator API misuse. > > We need to resolve this issue at the v4l2 core level though, as problems > like this appear more and more often. Thanks for the advice. Will probably have to deal with this in the near future. [1] http://roboforum.ru/forum36/topic7835.html -- 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
