From: Hans Verkuil <hverkuil@xs4all.nl>
To: Archit Taneja <archit@ti.com>
Cc: linux-media@vger.kernel.org, k.debski@samsung.com,
laurent.pinchart@ideasonboard.com, linux-omap@vger.kernel.org,
tomi.valkeinen@ti.com
Subject: Re: [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion
Date: Tue, 17 Dec 2013 12:49:03 +0100 [thread overview]
Message-ID: <52B03A2F.8030800@xs4all.nl> (raw)
In-Reply-To: <52B0335D.5060606@ti.com>
On 12/17/13 12:19, Archit Taneja wrote:
> Hi Hans,
>
> On Tuesday 17 December 2013 01:30 PM, Hans Verkuil wrote:
>> On 12/12/2013 09:35 AM, Archit Taneja wrote:
>>> The VPE and VIP IPs in DRA7x contain common scaler and color
>>> conversion hardware blocks. We create libraries for these
>>> components such that the vpe driver and the vip driver(in future)
>>> can use these library funcs to configure the blocks.
>>>
>>> There are some points for which I would like comments:
>>>
>>> - For VPE, setting the format and colorspace for the source and
>>> destination queues is enough to determine how these blocks need
>>> to be configured and whether they need to be bypassed or not. So
>>> it didn't make sense to represent them as media controller
>>> entities. For VIP(driver not upstream yet), it's possible that
>>> there are multiple data paths which may or may not include these
>>> blocks. However, the current use cases don't require such
>>> flexibility. There may be a need to re-consider a media
>>> controller like setup once we work on the VIP driver. Is it a
>>> good idea in terms of user-space compatibilty if we use media
>>> controller framework in the future.
>>
>> As long as you don't need the mc, then there is no need to
>> implement it.
>
> The thing is that we want to use these blocks for a future capture
> hardware called VIP. A VIP port can capture multiple streams from
> different sensors in time slices, and each of those streams might be
> sharing the same hardware, but probably in different configurations.
> I'm not completely aware of media controller details, and whether it
> can help us here.
>
> I was just wondering if it would be a problem if we later realise
> that mc might be useful for some use cases. Would implementing it
> then break previous user space applications which don't call mc
> ioctls?
My understanding is that in the current vpe driver the mc won't be
needed, so there is no point adding it. When implementing the vip
capture driver the mc might be needed, but that should not require
the vpe to add the mc API as well. It's a decision that has to be
made per driver.
When you start work on the vip driver it is probably a good idea to
talk to Laurent and myself first to see whether the mc is needed or
not.
If you have a block diagram of the video hardware that you can share,
then that will be quite useful.
Regards,
Hans
next prev parent reply other threads:[~2013-12-17 11:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 8:35 [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion Archit Taneja
2013-12-12 8:35 ` [PATCH 1/8] v4l: ti-vpe: create a scaler block library Archit Taneja
2013-12-12 8:35 ` [PATCH 2/8] v4l: ti-vpe: support loading of scaler coefficients Archit Taneja
2013-12-12 8:35 ` [PATCH 3/8] v4l: ti-vpe: make vpe driver load " Archit Taneja
2013-12-12 8:36 ` [PATCH 4/8] v4l: ti-vpe: enable basic scaler support Archit Taneja
2013-12-12 8:36 ` [PATCH 5/8] v4l: ti-vpe: create a color space converter block library Archit Taneja
2013-12-12 8:36 ` [PATCH 6/8] v4l: ti-vpe: Add helper to perform color conversion Archit Taneja
2013-12-12 8:36 ` [PATCH 7/8] v4l: ti-vpe: enable CSC support for VPE Archit Taneja
2013-12-12 8:36 ` [PATCH 8/8] v4l: ti-vpe: Add a type specifier to describe vpdma data format type Archit Taneja
2013-12-17 8:00 ` [PATCH 0/8] v4l: ti-vpe: Add support for scaling and color conversion Hans Verkuil
2013-12-17 11:19 ` Archit Taneja
2013-12-17 11:49 ` Hans Verkuil [this message]
2013-12-17 12:12 ` Archit Taneja
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=52B03A2F.8030800@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=archit@ti.com \
--cc=k.debski@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tomi.valkeinen@ti.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