From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sylwester Nawrocki <snjw23@gmail.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
hverkuil@xs4all.nl
Subject: Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Date: Wed, 10 Aug 2011 09:52:31 -0300 [thread overview]
Message-ID: <4E427F0F.7000902@redhat.com> (raw)
In-Reply-To: <4E424426.6080303@samsung.com>
Em 10-08-2011 05:41, Sylwester Nawrocki escreveu:
>>>> Why not? I never saw an embedded hardware that allows physically changing the
>>>> sensor.
>
> I understood Laurent's statement that you can have same ISP driver deployed on
> multiple boards fitted with various sensors. Hence the multiple configurations
> that cannot be known in advance,
True, but such kind of dependence should solved either at config time or at
probe time. It doesn't make any sense to show that a hardware is present, when
it is not. This applies to both V4L or MC APIs (and also to sysfs).
>>>> If V4L2 API is not enough, implementing it on libv4l won't solve, as userspace
>>>> apps will use V4L2 API for requresting it.
>>>
>>> There are two kind of applications: specialised and generic. The generic
>>> ones may rely on restrictive policies put in place by a libv4l plugin
>>> whereas the specialised applications need to access the device's features
>>> directly to get the most out of it.
>>
>> A submitted upstream driver should be capable of working with the existing
>> tools/userspace.
>>
>> Currently, there isn't such libv4l plugins (or, at least, I failed to see a
>> merged plugin there for N9, S5P, etc). Let's not upstream new drivers or remove
>> functionalities from already existing drivers based on something that has yet
>> to be developed.
>>
>> After having it there properly working and tested independently, we may consider
>> patches removing V4L2 interfaces that were obsoleted in favor of using the libv4l
>> implementation, of course using the Kernel way of deprecating interfaces. But
>> doing it before having it, doesn't make any sense.
>>
>> Let's not put the the cart before the horse.
>
> That's a good point. My long term plan was to deprecate and remove duplicated ioctls
> at the driver _once_ support for regular V4L2 interface on top of MC/subdev API
> is added at the v4l2 libraries. But this will happen after I create an initial..
> *cough* openmax IL for the driver. Which is not what the Tigers like best..
Ok.
>
> --
> Regards,
> Sylwester
next prev parent reply other threads:[~2011-08-10 12:52 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-27 16:35 [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates Sylwester Nawrocki
2011-07-28 2:55 ` Mauro Carvalho Chehab
2011-07-28 10:09 ` Sylwester Nawrocki
2011-07-28 13:20 ` Mauro Carvalho Chehab
2011-07-28 22:57 ` Sylwester Nawrocki
2011-07-29 4:02 ` Mauro Carvalho Chehab
2011-07-29 8:36 ` Laurent Pinchart
2011-08-09 20:05 ` Mauro Carvalho Chehab
2011-08-09 23:18 ` Sakari Ailus
2011-08-10 0:22 ` Mauro Carvalho Chehab
2011-08-10 8:41 ` Sylwester Nawrocki
2011-08-10 12:52 ` Mauro Carvalho Chehab [this message]
2011-08-15 12:45 ` Laurent Pinchart
2011-08-16 0:21 ` Mauro Carvalho Chehab
2011-08-16 8:59 ` Laurent Pinchart
2011-08-16 15:07 ` Mauro Carvalho Chehab
2011-08-15 12:30 ` Laurent Pinchart
2011-08-16 0:13 ` Mauro Carvalho Chehab
2011-08-16 8:57 ` Laurent Pinchart
2011-08-16 15:30 ` Mauro Carvalho Chehab
2011-08-16 15:44 ` Laurent Pinchart
2011-08-16 22:36 ` Mauro Carvalho Chehab
2011-08-17 7:57 ` Laurent Pinchart
2011-08-17 12:25 ` Mauro Carvalho Chehab
2011-08-17 12:37 ` Ivan T. Ivanov
2011-08-17 13:27 ` Mauro Carvalho Chehab
2011-08-17 12:33 ` Sakari Ailus
2011-08-16 21:47 ` Sylwester Nawrocki
2011-08-17 6:13 ` Embedded device and the V4L2 API support - Was: " Mauro Carvalho Chehab
2011-08-20 11:27 ` Sylwester Nawrocki
2011-08-20 12:12 ` Mauro Carvalho Chehab
2011-08-24 22:29 ` Sakari Ailus
2011-08-25 12:43 ` Mauro Carvalho Chehab
2011-08-26 13:45 ` Laurent Pinchart
2011-08-26 14:16 ` Hans Verkuil
2011-08-26 15:09 ` Mauro Carvalho Chehab
2011-08-26 15:29 ` Hans Verkuil
2011-08-26 17:32 ` Mauro Carvalho Chehab
2011-08-29 9:24 ` Laurent Pinchart
2011-08-29 14:53 ` Mauro Carvalho Chehab
2011-08-29 9:12 ` Laurent Pinchart
2011-08-30 20:34 ` Sakari Ailus
2011-08-03 14:28 ` Sylwester Nawrocki
2011-07-29 8:17 ` Sakari Ailus
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=4E427F0F.7000902@redhat.com \
--to=mchehab@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=snjw23@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox