From: Jonathan Cameron <jic23@cam.ac.uk>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: "Rodolfo Giometti" <giometti@enneenne.com>,
"Richard Röjfors" <richard.rojfors.ext@mocean-labs.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Mauro Carvalho Chehab" <mchehab@redhat.com>
Subject: Re: adv7180 as SoC camera device
Date: Mon, 22 Feb 2010 16:53:27 +0000 [thread overview]
Message-ID: <4B82B687.2080703@cam.ac.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.1002221706480.4120@axis700.grange>
On 02/22/10 16:16, Guennadi Liakhovetski wrote:
> On Mon, 22 Feb 2010, Rodolfo Giometti wrote:
>
>> On Fri, Feb 19, 2010 at 08:36:38PM +0100, Guennadi Liakhovetski wrote:
>>> On Fri, 19 Feb 2010, Rodolfo Giometti wrote:
>>>
>>>> Hello,
>>>>
>>>> on my pxa27x based board I have a adv7180 connected with the CIF
>>>> interface. Due this fact I'm going to use the pxa_camera.c driver
>>>> which in turn registers a soc_camera_host.
>>>>
>>>> In the latest kernel I found your driver for the ADV7180, but it
>>>> registers the chip as a v4l sub device.
>>>>
>>>> I suppose these two interfaces are not compatible, aren't they?
>>>
>>> Congratulations! Thereby you're in a position to develop the first
>>> v4l2-subdev / soc-camera universal driver;) The answer to this your
>>> question is - they are... kinda. This means - yes, soc-camera is also
>>> using the v4l2-subdev API, but - with a couple of additions. Basically,
>>> there are two things you have to change in the adv7180 driver to make it
>>> compatible with soc-camera - (1) add bus-configuration methods, even if
>>> they don't do much (see .query_bus_param() and .set_bus_param() methods
>>> from struct soc_camera_ops), and (2) migrate the driver to the mediabus
>>> API. The latter one requires some care - in principle, mediabus should be
>>> the future API to negotiate parameters on the video bus between bridges
>>> (in your case PXA CIF) and clients, but for you this means you also have
>>> to migrate any other bridge drivers in the mainline to that API, and, if
>>> they also interface to some other subdevices - those too, and if those can
>>> also work with other bridges - those too...;) But, I think, that chain
>>> will terminate quite soon, in fact, I cannot find any users of that driver
>>> currently in the mainline, Richard?
>>>
>>>> In this situation, should I write a new driver for the
>>>> soc_camera_device? Which is The-Right-Thing(TM) to do? :)
>>>
>>> Please, have a look and try to convert the driver as described above. All
>>> the APIs and a few examples are in the mainline, so, you should have
>>> enough copy-paste sources;) Ask on the list (with me on cc) if anything is
>>> still unclear.
>>
>> Thanks for your quick answer! :)
>>
>> What I still don't understand is if should I move the driver form
>> v4l2-subdev to a soc_camera device or trying to support both API...
>
> Both. It is just one (v4l2-subdev) API, but soc-camera is using some
> extensions to it.
>
>> It seems to me that the driver is not used by any machines into
>> mainline
>
> That makes your task even easier - you do not have to convert any bridge
> drivers to mediabus API.
Indeed. Having time to do that is what is delaying the ov7670 conversion.
(that and having time in general!) For info I did post some untested
patches for the ov7670 a while back that show the minimal changes I think
are needed under these circumstances.
>
>> so if soc-camera is also using the v4l2-subdev API but with a
>> couple of additions I suppose I can move it to soc_camera API...
>
> Not move, extend. But preserve an ability to function without soc-camera
> additions too. I.e., the use of soc-camera extensions should be optional
> in your driver. Look here
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/11486/focus=11493
> for an example.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2010-02-22 16:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 17:44 adv7180 as SoC camera device Rodolfo Giometti
2010-02-19 19:36 ` Guennadi Liakhovetski
2010-02-22 16:01 ` Rodolfo Giometti
2010-02-22 16:11 ` Hans Verkuil
2010-02-22 16:15 ` Rodolfo Giometti
2010-02-22 16:46 ` Guennadi Liakhovetski
2010-02-22 16:16 ` Guennadi Liakhovetski
2010-02-22 16:53 ` Jonathan Cameron [this message]
2010-02-22 23:19 ` Richard Röjfors
2010-03-30 14:06 ` Rodolfo Giometti
2010-03-30 14:40 ` Guennadi Liakhovetski
2010-03-30 15:42 ` Rodolfo Giometti
2010-04-02 7:06 ` Guennadi Liakhovetski
2010-04-01 11:48 ` Rodolfo Giometti
2010-04-02 7:09 ` Guennadi Liakhovetski
2010-04-02 7:44 ` Rodolfo Giometti
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=4B82B687.2080703@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=g.liakhovetski@gmx.de \
--cc=giometti@enneenne.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=richard.rojfors.ext@mocean-labs.com \
/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.