Hi Andrey,
Cc: LMML
On 11/04/2012 09:43 PM, Andrey Gusakov wrote:
Hi all.
I'm testing your FIMC driver on S3C6410 hardware with OV9650 (in plans
OV2640).
I fixed some register definition, gpio init, fixed IRQ handling for
S3C6410. So now i can get test frames from internal pattern generator.
But when i try to read from external sensor i got blue or green trash.
Does it change when external light conditions change ? Or is it completely
random ?
Yes. When it's dark - almost all picture is green. when I light on
sensor, picture become more noisy with more blue pixels.
If i comment out ov965x_init_regs write to sensor, I get black and
white noise, like on TV when no signal.
My opinion is there is some mistmatch in formats between sensor and FIMC.
Yes, I also suspect this is the root cause.
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 ?
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.
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'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.
Best regards.
Andrey.
--
Regards,
Sylwester
--
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
