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

Benjamin Deering ben_deering at swissmail.org
Mon Feb 11 13:20:59 CET 2013


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.
>
> The key issue appears to me that there are two almost incompatible
> approaches to integrate cameras into the kernel and this requires 
> different
> camera module drivers. So as a new first step we have to decide which
> one will be supported in the future.
>
> Anyways we can use the ov9640 driver from soc_camera to learn how to
> initialize the registers in a better way than we currently have.
>
> So the key question we should answer first before continuing is which
> method of camera integration is best supported by the Linux community.
>
> 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/20130211/ea9d38c9/attachment-0001.html>


More information about the Gta04-owner mailing list