From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Bastian Hecht <hechtb@googlemail.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
laurent.pinchart@ideasonboard.com
Subject: Re: OMAP 3530 camera ISP forks and new media framework
Date: Thu, 07 Oct 2010 13:58:53 +0300 [thread overview]
Message-ID: <4CADA7ED.5020604@maxwell.research.nokia.com> (raw)
In-Reply-To: <AANLkTimyR117ZiHq8GFz4YW5tBtW3k82NzGVZqKoVTbY@mail.gmail.com>
Bastian Hecht wrote:
> Hello media team,
Hi Bastian,
> I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> chip and start getting confused about the different kernel forks and
> architectural changes that happen in V4L2.
> A similar problem was discussed in this mailing list at
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
>
> Currently I don't know which branch to follow. Either
> http://gitorious.org/omap3camera from Sakari Ailus or the branch
> media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> written for the new media controller architecture if I am right.
Take Laurent's branch it has all the current patches in it. My gitorious
tree isn't updated anymore. (I just had forgotten to add a note, it's
there now.)
> I see in http://gitorious.org/omap3camera/camera-firmware that there
> is already an empty placeholder for the mt9t031.
> The README of the camera-firmware repository states: "makemodes.pl is
> a perl script which converts sensor register lists from FIXME into C
> code. dcc-pulautin is a Makefile (mostly) that converts sensor
> register lists as C code into binaries understandable to sensor
> drivers. The end result is a binary with sensor driver name, sensor
> version and bin suffix, for example et8ek8-0002.bin."
>
> So I think the goal is to provide a script framework for camera
> systems. You just script some register tables and it creates a binary
> that can be read by a sensor driver made for that framework. If the a
> camera bridge driver for your chip exists, you are done. Am I right?
> Are drivers/media/video/et8ek8.c and
> drivers/staging/dream/camera/mt9p012_* such drivers?
et8ek8 and smia-sensor currently use the camera-firmware binaries. The
long term goal is to move more things to the sensor driver itself.
Register lists related to a set of sensor settings are not an ideal way
to handle sensor related settings since they could be controlled the
driver instead.
> So do you think it is the right way to go to use your ISP driver,
> adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
> write a register list and create a camera firmware for that sensor
> driver with makemodes?
I would go with drivers/media/video/et8ek8.c in Laurent's tree instead
if you want to write a sensor driver to be used with the OMAP 3 ISP
driver. Register lists are not that nice but the v4l2_subdev interface
in that one is one of the good parts you get with that.
I'd also advice against using camera-firmware if you don't necessarily
need that kind of functionality.
> I am still quite confused... if I get something wrong, please give me
> some hints.
I hope this helped. :-)
If you have any further questions feel free to ask.
Cheers,
--
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com
next prev parent reply other threads:[~2010-10-07 10:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 9:42 OMAP 3530 camera ISP forks and new media framework Bastian Hecht
2010-10-07 10:58 ` Sakari Ailus [this message]
2010-10-07 13:27 ` Laurent Pinchart
2010-10-07 13:52 ` Hiremath, Vaibhav
2010-10-07 18:15 ` Guennadi Liakhovetski
2010-10-08 10:46 ` Bastian Hecht
2010-10-11 12:59 ` Bastian Hecht
2010-10-11 13:14 ` Laurent Pinchart
2010-10-11 14:58 ` Bastian Hecht
2010-10-11 15:07 ` Laurent Pinchart
2010-10-12 12:10 ` Bastian Hecht
2010-10-12 12:58 ` Laurent Pinchart
2010-10-14 13:10 ` Bastian Hecht
2010-10-14 13:28 ` Laurent Pinchart
2010-10-12 13:02 ` Bastian Hecht
2010-10-13 22:03 ` Eino-Ville Talvala
2010-10-13 22:58 ` Laurent Pinchart
2010-10-14 5:18 ` Eino-Ville Talvala
2010-10-14 23:08 ` Laurent Pinchart
2010-10-28 10:28 ` Michael Jones
2010-10-28 13:24 ` Laurent Pinchart
2010-10-11 15:26 ` Guennadi Liakhovetski
2010-10-11 16:13 ` Bastian Hecht
2010-10-22 13:54 ` Michael Jones
2010-10-22 14:13 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CADA7ED.5020604@maxwell.research.nokia.com \
--to=sakari.ailus@maxwell.research.nokia.com \
--cc=hechtb@googlemail.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.