[Gta04-owner] Camera and PVR/SGX patches for Kernel 3.7 - need help
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon Feb 11 13:58:30 CET 2013
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...
>>
>> 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
>
> _______________________________________________
> 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/c5787d04/attachment-0001.html>
More information about the Gta04-owner
mailing list