[Gta04-owner] Camera and PVR/SGX patches for Kernel 3.7 - need help

Dr. H. Nikolaus Schaller hns at goldelico.com
Wed Feb 13 19:09:59 CET 2013

Am 11.02.2013 um 13:58 schrieb Dr. H. Nikolaus Schaller:

> Am 11.02.2013 um 13:20 schrieb Benjamin Deering:
>> On 02/11/2013 05:02 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 09.02.2013 um 18:08 schrieb Benjamin Deering:
>>>> On 02/07/2013 06:08 PM, Benjamin Deering wrote:
>>>>> On 01/31/2013 03:34 AM, Dr. H. Nikolaus Schaller wrote: 
>>>>>> Am 31.01.2013 um 05:19 schrieb Benjamin Deering: 
>>>>>>> On 01/27/2013 11:37 AM, Dr. H. Nikolaus Schaller wrote: 
>>>>>>>> Hi all, 
>>>>>>>> I have finally found some time to patch Neils 3.7 kernel to include 
>>>>>>>> the OV9655 and the PVR/SGX drivers like the old hw-validation kernel 
>>>>>>>> did. 
>>>>>>>> And I have added the panel driver for the OpenPhoenux 3704 device. 
>>>>>>>> But only the last one works. 
>>>>>>>> a) the OV9655 can be compiled, modprobed and shows up in 
>>>>>>>> lsmod - but nothing significant happens. It also loads nearly 10 
>>>>>>>> other modules for soc_camera and v4l2. 
>>>>>>>> It does neither call the driver's probe() function nor the power 
>>>>>>>> on/off management code that I have added to the gta04 board 
>>>>>>>> file. 
>>>>>>>> Does anyone know if the camera-soc interface really works for 
>>>>>>>> OMAP3? And what has to be done in addition to adding the 
>>>>>>>> driver structures in the board file to initialize it? 
>>>>>>>> Another note: the ov9655.c I have created is more or less a 
>>>>>>>> copy of the ov9640.c which appears to have almost the same 
>>>>>>>> register set - but since I have only a ov9640.h and no data 
>>>>>>>> sheet, the differences in detail are not clear. So it is not clear 
>>>>>>>> if the driver itself configures the camera correctly. But before 
>>>>>>>> it is probed that is a lower priority obstacle. 
>>>>>>>> One more note: this implementation approach is completely different 
>>>>>>>> from the old hw-validation kernel, where we did have a special 
>>>>>>>> TI image processing kernel driver and the ov9655 defined 
>>>>>>>> there only shares some initialization bit patterns. 
>>>>>>>> b) I have downloaded the latest Graphics_SDK_4_08_00_01.bin 
>>>>>>>> from TI, unpacked and have done the same integration approach 
>>>>>>>> as for the 2.6.32 kernel. 
>>>>>>>> After fixing the Makefile and the -D options plus some (minor?) changes 
>>>>>>>> to cope with kernel source changes after Linux 3.4 it finally compiled 
>>>>>>>> fine, but the kernel does not boot any more: 
>>>>>>>> Environment size: 2996/131068 bytes 
>>>>>>>> lcm state set to deep-standby 
>>>>>>>> display power off 
>>>>>>>> ## Booting kernel from Legacy Image at 82000000 ... 
>>>>>>>>    Image Name:   Linux-3.7.0-offmode-gta04 
>>>>>>>>    Image Type:   ARM Linux Kernel Image (uncompressed) 
>>>>>>>>    Data Size:    3191216 Bytes = 3 MiB 
>>>>>>>>    Load Address: 80008000 
>>>>>>>>    Entry Point:  80008000 
>>>>>>>>    Verifying Checksum ... OK 
>>>>>>>>    Loading Kernel Image ... OK 
>>>>>>>> OK 
>>>>>>>> Starting kernel ... 
>>>>>>>> Uncompressing Linux... done, booting the kernel. 
>>>>>>>> ---- here it hangs ---- 
>>>>>>>> What I had to do is to configure video/gpudrm and PCI support to get it compiled. 
>>>>>>>> Especially the PCI thing is a little weird, since the TI SDK comes with a stub 
>>>>>>>> library that should replace everything from PCI. But that one doesn't compile. 
>>>>>>>> After deconfiguring SGX, DRM, PCI, it still compiles and now, the kernel boots again. 
>>>>>>>> The complete source tree is available here: 
>>>>>>>> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/hw-validation-3.x> 
>>>>>>>> <https://github.com/goldelico/gta04-kernel/commits/hw-validation-3.x> 
>>>>>>>> (you need to actively configure SGX530 first). 
>>>>>>>> Any ideas how to debug these issues? Anyone trying his/her luck? 
>>>>>>>> Nikolaus 
>>>>>>>> _______________________________________________ 
>>>>>>>> Gta04-owner mailing list 
>>>>>>>> Gta04-owner at goldelico.com 
>>>>>>>> http://lists.goldelico.com/mailman/listinfo/gta04-owner 
>>>>>>> With this change, ov9655 tries to probe, but fails: 
>>>>>>> [ 1259.122161] ov9655 2-0030: Missing platform_data for driver 
>>>>>>> [ 1259.122192] ov9655: probe of 2-0030 failed with error -22 
>>>>>>> It looks like that may be a known issue in the board file? 
>>>>>> Well, the board file is known to be incomplete at this location... 
>>>>>> The hw-validation kernel did have a completely separate file 
>>>>>> to extend the board file and this is just a first integration step. 
>>>>>> The hint for the missing platform_data is ver good. I have looked 
>>>>>> into the board file and found one missing initialization. Let's 
>>>>>> see if this solves some issues. 
>>>>>> BR, 
>>>>>> Nikolaus 
>>>>>> _______________________________________________ 
>>>>>> Gta04-owner mailing list 
>>>>>> Gta04-owner at goldelico.com 
>>>>>> http://lists.goldelico.com/mailman/listinfo/gta04-owner 
>>>>> 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. 
>>>>> When it does the i2c_transfer, client->addr is not a value I would expect.  Forcing it to 0x30 still doesn't work. 
>>>>> 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. 
>>>>> Ben 
>>>>> _______________________________________________
>>>>> Gta04-owner mailing list
>>>>> Gta04-owner at goldelico.com
>>>>> http://lists.goldelico.com/mailman/listinfo/gta04-owner
>>>> It looks like I was wrong about some things.  client->addr is 0x30 like I would expect.
>>>> Something strange is that I am not seeing anything from i2cdump -y 2 0x30.  
>>> You should see an "U" meaning that there is already a platform driver feeling responsible. At least when you modprobe ov9655.
>>>> 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
>>>> 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?
>>> I think we need xclk for I2C operation.
>>> I wasn't able to get it probed at all and did not get a /dev/video.
>>> Maybe because xclk is missing.
>>>> 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.  
>>> That is strange. Did you configure for SOC_CAMERA_OV9655?
>> I think I did.  All of the appropriate modules are built.
>>> Now, I have found some (not so good) news:
>>> 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
>>> There is no omap2_camera.c or omap3_camera.c and that is most likely
>>> the lacking element to initialize the xclk and capture interface.
>>> IMHO it could be possible to write such a driver based on the
>>> omap1_camera.c code. But debugging and making it work is a lot of work...
>>> Alternatively, we could find some project that already has a soc_camera/omap3_camera.c
>>> Or we scrap everything done so far and start over based on the omap3isp
>>> driver and our own ov9655 driver from the hw-validation kernel.
>> I think that sounds right.  I found this last night:
>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/19723
>> 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.
> Well it does not look as if the soc_camera is really deprecated, but it is intended
> for "simple" camera interfaces.
> But the DM3730 has a full video processing pipeline that can do much more
> (automatic white balance, filtering, gamma correction) and all these features
> can't be controlled through the "simple" soc_camera.
> But apparently they can through this sub-device framework.
> There is also some documentation:
> http://lxr.linux.no/linux+v3.7.6/Documentation/video4linux/omap3isp.txt
> talking about these subdevices and their features. To me it appears that they
> introduce additional ioctls for these advanced features. There is also reference
> to some media control user-space tool:
> http://git.ideasonboard.org/media-ctl.git/tree
> It looks that we already were on the right track with the hw-validation kernel
> way of integration but I was confused by the finding that there is a soc_camera
> driver for the ov9640 camera module...
> So please give me some days to redo these changes to the 3.7 kernel tree
> and fix kernel API compatibility issues...

Well, I have started to analyze this better. The result is: there isn't an OMAP3 camera driver either!

Although the ISP (Image Signal Processing) driver with many features is in mainline.


All the isp files are there, but e.g. omap34xxcam.c and omap34xxcam.h are missing.

So I can only shake my head, because I don't want to believe that we are the only
ones who want to interface a camera to an OMAP3 and use the mainline kernel.

The OMAP3 is available since approx. 2009 and many devices are using it but
no complete camera system has found its way into the kernel...

We have to find the omap-34xxcam files/patches elsewhere. Maybe
something like this:


But I don't know if that is the latest one or the best approach. And if it is complete.
The camera board file extension uses e.g. struct isp_interface_config
which I also can't find in the kernel sources.

I think someone with access to the linux kernel developers mailing list
should ask what the best way is (maybe there is something upcoming in
future kernels or pending for integration) to interface a SoC camera to
an OMAP3 using the mainline kernel and where good examples can be

A general overview how the ISP drivers should work is here:


And the ISP system is documented here - but no examples how
to add/configure a sensor (driver):



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20130213/c588c031/attachment-0001.html>

More information about the Gta04-owner mailing list