[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

hacking MT9P031 (LI-5M03) driver in Ubuntu 12.04 on BeagleBoard xM?

Hi. I was redirected to this list by a response to my post (below) on the BeagleBoard group. I'm happy to help/cooperate/etc. in whatever way I reasonably can.

-------- Original Message --------

Hello, all.

I managed to get the MT9P031 driver (for the Leopard Imaging LI-5M03 camera board) working using a slightly modified Ubuntu 12.04 kernel, including the mainline kernel version of the MT9P031 driver. Once everything is clean and happy I will post info for those still trying to get there. Meanwhile, though, there are some odd issues, and a few driver bugs I need to fix and features I need to add. I wanted to reach out to others who are working with this hardware in current (not Angstrom 2.6.x) kernels so we can compare notes, and so we don't go off in the wrong (or a different) direction on solving some of the problems.

For our application, we are capturing video in raw format (raw Bayer), with MT9P031 -> CCDC -> CCDC output (no resizer etc.), reading from /dev/video2. The new media controller framework is pretty cool once you get the hang of it - it addresses some significant deficiencies. I just wish the new subdev selection was available, but it's not in 3.2.x... hopefully we can move to 3.5 soon and then I just need to implement it in the MT9P031 driver (if someone else doesn't do that before I get there).

Some of the issues:

1. To get it working, I had to patch in the Aptina driver mods for board-omap3beagle.c etc. I'm not at all sure this is kosher since I'm using the mainline kernel driver, not the Aptina driver (nor the RidgeRun one, in which I had to fix a lot of bugs when we were doing this on a Leopardboard). But without these changes, the camera was not recognized (likely because it wasn't being powered up). I would think that someone out there must be using the driver in the mainline kernel, since it's in there, but how are they getting the camera to be recognized?

2. Max frame rate at full resolution seems to be 6.86 fps. I think we're running at half clock speed. We'd like to fix that. I can track it down, but I don't want to duplicate work already done by someone else, and of course this likely relates to issue # 1, above.

3. When I start streaming, then stop streaming, then start streaming again without closing and reopening the device in between (and sometimes even if I do but reopen right after closing), the second time we start streaming, it appears that the green and non-green (red or blue as the case may be) pixels are swapped - as if it was offset by one column. But if I change the cropping (using VIDIOC_SUBDEV_S_FMT on /ev/v4l-subdev8, which is the MT9P031 directly) to include the black (inactive) pixels on the top and left, it is still true - but the black pixels don't change, only the active ones, even though they still start at the same offset (+10,+50 IIRC). I don't even see how that should be possible. The MT9P031 registers (all of them) are the same whether the swapping is occurring or not, and ditto for the CCDC registers per the dump in the kernel log. Has anyone else seen this? I have worked around it for now by closing the device (all of them), sleeping for 2 ms, and then reopening and reconfiguring. However, I'd really like to find a proper solution, or at least understand the root cause - it's kind of disturbing, especially since without the sleep it still didn't reliably work correctly. This may also relate to issue # 1, above.

4. I need to add some additional controls (like a way to manipulate the vblank register setting so we can reduce the frame rate without just randomly dropping frames - we want to adjust the frame rate to what we can fairly reliably store without dropping frames - and access to the separate gain controls for R, Gr, Gb, and B, since we're using color sensors (cheaper) with IR illumination). I'd like to get some feedback on the most appropriate way to do this. Obviously I could just hack it in, but I'd rather do it right and hopefully get it into the mainline driver. In 3.5-rc2, I see a definition for a VBLANK control, but it still isn't clear what ought to be used for separate gain controls.

5. The driver (and likewise the CCDC driver) needs a few small fixes, and I'd like to avoid duplication of effort, etc.

      Chris MacGregor

To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Linux Input]     [Video for Linux]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Devices]     [Yosemite Backpacking]

Add to Google Powered by Linux