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

Benjamin Deering ben_deering at swissmail.org
Thu Feb 14 14:03:36 CET 2013

On 02/13/2013 01:09 PM, Dr. H. Nikolaus Schaller wrote:
> 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.
> <http://omappedia.org/index.php?title=Camera-ISP_Driver#Camera_ISP_driver_files_and_locations>
> 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:
> <http://linux.omap.com/pub/kernel/3430sdp/patches-applicable-over-linux-omap-2.6.git/omap34xxcam.patch>
> 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. structisp_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
> found.
> A general overview how the ISP drivers should work is here:
> <http://omappedia.org/index.php?title=Camera-ISP_Driver>

Is this the new system: 
http://omappedia.org/index.php?title=Camera-ISP_Driver#Media_Controller ?

Some of the links for progress from that page are broken, but looking 
around on the site they link to I found this:

There are changes for supporting some ov camera on beagleboard and it 
looks like a newish kernel.  I'm still not clear on all the terms 
(mediacontroller, subdev, isp, etc) so I need to do more research before 
I will even know when I've found the right code.

> And the ISP system is documented here - but no examples how
> to add/configure a sensor (driver):
> <http://lxr.linux.no/linux+v3.0.4/Documentation/video4linux/omap3isp.txt>
> BR,
> Nikolaus
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner

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

More information about the Gta04-owner mailing list