<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 11.02.2013 um 13:20 schrieb Benjamin Deering:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
On 02/11/2013 05:02 AM, Dr. H. Nikolaus Schaller wrote:
<blockquote cite="mid:416444D4-1BC2-4053-B605-92CA04F57E3D@goldelico.com" type="cite"><br>
<div>
<div>Am 09.02.2013 um 18:08 schrieb Benjamin Deering:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF"> On 02/07/2013 06:08 PM,
Benjamin Deering wrote:
<blockquote cite="mid:511433D8.9070209@swissmail.org" type="cite">On 01/31/2013 03:34 AM, Dr. H. Nikolaus
Schaller wrote: <br>
<blockquote type="cite">Am 31.01.2013 um 05:19 schrieb
Benjamin Deering: <br>
<br>
<blockquote type="cite">On 01/27/2013 11:37 AM, Dr. H.
Nikolaus Schaller wrote: <br>
<blockquote type="cite">Hi all, <br>
I have finally found some time to patch Neils 3.7
kernel to include <br>
the OV9655 and the PVR/SGX drivers like the old
hw-validation kernel <br>
did. <br>
<br>
And I have added the panel driver for the
OpenPhoenux 3704 device. <br>
<br>
But only the last one works. <br>
<br>
a) the OV9655 can be compiled, modprobed and shows
up in <br>
lsmod - but nothing significant happens. It also
loads nearly 10 <br>
other modules for soc_camera and v4l2. <br>
<br>
It does neither call the driver's probe() function
nor the power <br>
on/off management code that I have added to the
gta04 board <br>
file. <br>
<br>
Does anyone know if the camera-soc interface really
works for <br>
OMAP3? And what has to be done in addition to adding
the <br>
driver structures in the board file to initialize
it? <br>
<br>
Another note: the ov9655.c I have created is more or
less a <br>
copy of the ov9640.c which appears to have almost
the same <br>
register set - but since I have only a ov9640.h and
no data <br>
sheet, the differences in detail are not clear. So
it is not clear <br>
if the driver itself configures the camera
correctly. But before <br>
it is probed that is a lower priority obstacle. <br>
<br>
One more note: this implementation approach is
completely different <br>
from the old hw-validation kernel, where we did have
a special <br>
TI image processing kernel driver and the ov9655
defined <br>
there only shares some initialization bit patterns.
<br>
<br>
<br>
b) I have downloaded the latest
Graphics_SDK_4_08_00_01.bin <br>
from TI, unpacked and have done the same integration
approach <br>
as for the 2.6.32 kernel. <br>
<br>
After fixing the Makefile and the -D options plus
some (minor?) changes <br>
to cope with kernel source changes after Linux 3.4
it finally compiled <br>
fine, but the kernel does not boot any more: <br>
<br>
<br>
Environment size: 2996/131068 bytes <br>
lcm state set to deep-standby <br>
display power off <br>
## Booting kernel from Legacy Image at 82000000 ...
<br>
Image Name: Linux-3.7.0-offmode-gta04 <br>
Image Type: ARM Linux Kernel Image
(uncompressed) <br>
Data Size: 3191216 Bytes = 3 MiB <br>
Load Address: 80008000 <br>
Entry Point: 80008000 <br>
Verifying Checksum ... OK <br>
Loading Kernel Image ... OK <br>
OK <br>
<br>
Starting kernel ... <br>
<br>
Uncompressing Linux... done, booting the kernel. <br>
<br>
---- here it hangs ---- <br>
<br>
<br>
What I had to do is to configure video/gpudrm and
PCI support to get it compiled. <br>
<br>
Especially the PCI thing is a little weird, since
the TI SDK comes with a stub <br>
library that should replace everything from PCI. But
that one doesn't compile. <br>
<br>
After deconfiguring SGX, DRM, PCI, it still compiles
and now, the kernel boots again. <br>
<br>
<br>
The complete source tree is available here: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/hw-validation-3.x"><http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/hw-validation-3.x></a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="https://github.com/goldelico/gta04-kernel/commits/hw-validation-3.x"><https://github.com/goldelico/gta04-kernel/commits/hw-validation-3.x></a>
<br>
<br>
(you need to actively configure SGX530 first). <br>
<br>
Any ideas how to debug these issues? Anyone trying
his/her luck? <br>
<br>
Nikolaus <br>
<br>
_______________________________________________ <br>
Gta04-owner mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.goldelico.com/mailman/listinfo/gta04-owner">http://lists.goldelico.com/mailman/listinfo/gta04-owner</a>
<br>
<br>
</blockquote>
With this change, ov9655 tries to probe, but fails: <br>
[ 1259.122161] ov9655 2-0030: Missing platform_data
for driver <br>
[ 1259.122192] ov9655: probe of 2-0030 failed with
error -22 <br>
<br>
It looks like that may be a known issue in the board
file? <br>
</blockquote>
Well, the board file is known to be incomplete at this
location... <br>
<br>
The hw-validation kernel did have a completely separate
file <br>
to extend the board file and this is just a first
integration step. <br>
<br>
The hint for the missing platform_data is ver good. I
have looked <br>
into the board file and found one missing
initialization. Let's <br>
see if this solves some issues. <br>
<br>
BR, <br>
Nikolaus <br>
<br>
<br>
_______________________________________________ <br>
Gta04-owner mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.goldelico.com/mailman/listinfo/gta04-owner">http://lists.goldelico.com/mailman/listinfo/gta04-owner</a>
<br>
<br>
</blockquote>
I spent some more time with this during this week. I am
probably missing something obvious to others, but the
i2c_transfers are failing so I can't read any registers
from ov9655. <br>
<br>
When it does the i2c_transfer, client->addr is not a
value I would expect. Forcing it to 0x30 still doesn't
work. <br>
<br>
If I can get some help with this, I will keep working on
it, but otherwise I think I might leave it alone for a
while. <br>
<br>
Ben <br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gta04-owner mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.goldelico.com/mailman/listinfo/gta04-owner">http://lists.goldelico.com/mailman/listinfo/gta04-owner</a>
</pre>
</blockquote>
It looks like I was wrong about some things.
client->addr is 0x30 like I would expect.<br>
<br>
Something strange is that I am not seeing anything from
i2cdump -y 2 0x30. </div>
</blockquote>
<div><br>
</div>
<div>You should see an "U" meaning that there is already a
platform driver feeling responsible. At least when you
modprobe ov9655.</div>
<br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"> I started the
hw-validation image and confirmed that the ov9655 driver
loaded and the usual garbage showed on the screen. When the
ov9655 module is unloaded, i2cdump behaves the same on
hw-validation image as it does with 3.7<br>
<br>
I noticed that there is nothing in the 3.7 kernel to deal
with xclk for camera. Does it need xclk for i2c to work
correctly?<br>
</div>
</blockquote>
<div><br>
</div>
I think we need xclk for I2C operation.</div>
<div><br>
</div>
<div>I wasn't able to get it probed at all and did not get a
/dev/video.</div>
<div><br>
</div>
<div>Maybe because xclk is missing.</div>
<div><br>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"> <br>
At least in my build, I need to #define
CONFIG_SOC_CAMERA_OV9655 at the top of the board file or
none of the camera related code is compiled. <br>
</div>
</blockquote>
<div><br>
</div>
That is strange. Did you configure for SOC_CAMERA_OV9655?</div>
<div><br>
</div>
</blockquote>
I think I did. All of the appropriate modules are built.<br>
<blockquote cite="mid:416444D4-1BC2-4053-B605-92CA04F57E3D@goldelico.com" type="cite">
<div>Now, I have found some (not so good) news:</div>
<div><br>
</div>
<div><a moz-do-not-send="true" href="http://lxr.free-electrons.com/source/drivers/media/platform/soc_camera/soc_camera.c">http://lxr.free-electrons.com/source/drivers/media/platform/soc_camera/soc_camera.c</a></div>
<div><a moz-do-not-send="true" href="http://lxr.free-electrons.com/source/drivers/media/platform/soc_camera">http://lxr.free-electrons.com/source/drivers/media/platform/soc_camera</a></div>
<div><br>
</div>
<div>There is no omap2_camera.c or omap3_camera.c and that is most
likely</div>
<div>the lacking element to initialize the xclk and capture
interface.</div>
<div><br>
</div>
<div>IMHO it could be possible to write such a driver based on the</div>
<div>omap1_camera.c code. But debugging and making it work is a
lot of work...</div>
<div>Alternatively, we could find some project that already has a
soc_camera/omap3_camera.c</div>
<div><br>
</div>
<div>Or we scrap everything done so far and start over based on
the omap3isp</div>
<div>driver and our own ov9655 driver from the hw-validation
kernel.</div>
</blockquote>
I think that sounds right. I found this last night:<br>
<a href="http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/19723">http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/19723</a><br>
This seems to suggest that soc_camera is deprecated and the new
framework is called "Sub-device". The thread linked about discusses
3 approaches and suggests that soc_camera for OMAP3 was never
finished.<br></div></blockquote><div><br></div>Well it does not look as if the soc_camera is really deprecated, but it is intended</div><div>for "simple" camera interfaces.</div><div><br></div><div>But the DM3730 has a full video processing pipeline that can do much more</div><div>(automatic white balance, filtering, gamma correction) and all these features</div><div>can't be controlled through the "simple" soc_camera.</div><div><br></div><div>But apparently they can through this sub-device framework.</div><div><br></div><div>There is also some documentation:</div><div><br></div><div><a href="http://lxr.linux.no/linux+v3.7.6/Documentation/video4linux/omap3isp.txt">http://lxr.linux.no/linux+v3.7.6/Documentation/video4linux/omap3isp.txt</a></div><div><br></div><div>talking about these subdevices and their features. To me it appears that they</div><div>introduce additional ioctls for these advanced features. There is also reference</div><div>to some media control user-space tool:</div><div><br></div><div><a href="http://git.ideasonboard.org/media-ctl.git/tree">http://git.ideasonboard.org/media-ctl.git/tree</a></div><div><br></div><div>It looks that we already were on the right track with the hw-validation kernel</div><div>way of integration but I was confused by the finding that there is a soc_camera</div><div>driver for the ov9640 camera module...</div><div><br></div><div>So please give me some days to redo these changes to the 3.7 kernel tree</div><div>and fix kernel API compatibility issues...</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<blockquote cite="mid:416444D4-1BC2-4053-B605-92CA04F57E3D@goldelico.com" type="cite">
<div><br>
</div>
<div>The key issue appears to me that there are two almost
incompatible</div>
<div>approaches to integrate cameras into the kernel and this
requires different</div>
<div>camera module drivers. So as a new first step we have to
decide which</div>
<div>one will be supported in the future.</div>
<div><br>
</div>
<div>Anyways we can use the ov9640 driver from soc_camera to learn
how to</div>
<div>initialize the registers in a better way than we currently
have.</div>
<div><br>
</div>
<div>So the key question we should answer first before continuing
is which</div>
<div>method of camera integration is best supported by the Linux
community.</div>
<div><br>
</div>
<div>BR,</div>
<div>Nikolaus</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gta04-owner mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a>
<a class="moz-txt-link-freetext" href="http://lists.goldelico.com/mailman/listinfo/gta04-owner">http://lists.goldelico.com/mailman/listinfo/gta04-owner</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>Gta04-owner mailing list<br><a href="mailto:Gta04-owner@goldelico.com">Gta04-owner@goldelico.com</a><br>http://lists.goldelico.com/mailman/listinfo/gta04-owner<br></blockquote></div><br></body></html>