From: Philipp Zabel <p.zabel@pengutronix.de>
To: Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
ML dri-devel <dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Steve Longerbeam <slongerbeam@gmail.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
Kamil Debski <k.debski@samsung.com>,
Ian Molton <imolton@ad-holdings.co.uk>,
Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com>,
Sascha Hauer <kernel@pengutronix.de>,
Sascha Hauer <s.hauer@pengutronix.de>,
Lucas Stach <l.stach@pengutronix.de>
Subject: Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Date: Thu, 28 May 2015 12:35:29 +0200 [thread overview]
Message-ID: <1432809329.3228.19.camel@pengutronix.de> (raw)
In-Reply-To: <CAH-u=82OC=r+kgyHpvQFLMwrBiuaV_V3Q7W5FKV3eK4o_n0-HA@mail.gmail.com>
Hi Jean-Michel,
Am Mittwoch, den 27.05.2015, 20:42 +0200 schrieb Jean-Michel Hautbois:
[...]
> > The tiling code has a parameter to optionally round frame sizes up or down
> > and avoid overdraw in compositing scenarios.
>
> Can you detail what you call "compositing scenarios" ?
I meant using the v4l2 selection API to draw the scaled result into a
compose rectangle in a larger v4l2 capture buffer. To avoid overdrawing
pixels outside of the rectangle, its right edge must be aligned with the
burst size of the rightmost tiles.
[...]
> > @@ -152,6 +203,19 @@ struct ipu_ic {
> > bool in_use;
> >
> > struct ipu_ic_priv *priv;
> > +
> > + struct ipuv3_channel *input_channel_p;
> > + struct ipuv3_channel *input_channel;
> > + struct ipuv3_channel *input_channel_n;
> > + struct ipuv3_channel *output_channel;
> > + struct ipuv3_channel *rotation_input_channel;
> > + struct ipuv3_channel *rotation_output_channel;
> > +
> > + struct list_head image_list;
> > +
> > + struct workqueue_struct *workqueue;
> > + struct work_struct work;
> > + struct completion complete;
> > };
>
> As this is a workqueue, it can sleep, and you don't know when it is
> called exactly.
> Can we be sure that it is "real-time" compatible ? If you have this
> scaler after a capture source, and before the coda driver, you can be
> starved of buffers ?
> And you can even have multiple instances of the scaler, so you
> probably can get into troubles if there is not enough buffers on the
> capture and output queues, right ?
When there are no buffers available, the m2m scaler won't run. What do
you mean by "real-time" compatible? We can't make any guarantees that
scaling will be finished in a certain timeframe in general, as the
scaler competes with other hardware units for memory bandwidth, which
often is the limiting factor.
If multiple scaling instances are run on the same IPU, they will take
turns using the IC.
> I have played with it a bit and have been successful having two
> instances on IPU1 and two other on IPU2.
> But I don't know if there can be side effects...
regards
Philipp
next prev parent reply other threads:[~2015-05-28 10:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 10:22 [PATCH v2 0/5] i.MX5/6 mem2mem scaler Philipp Zabel
2015-03-18 10:22 ` [PATCH v2 1/5] gpu: ipu-v3: Add missing IDMAC channel names Philipp Zabel
2015-03-18 10:22 ` [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC Philipp Zabel
2015-05-27 18:42 ` Jean-Michel Hautbois
2015-05-28 9:00 ` Enrico Weigelt, metux IT consult
2015-05-28 10:44 ` Philipp Zabel
2015-05-28 11:31 ` Enrico Weigelt, metux IT consult
2015-05-28 11:59 ` Philipp Zabel
2015-05-28 17:38 ` Enrico Weigelt, metux IT consult
2015-05-28 17:54 ` Robert Schwebel
2015-05-29 9:02 ` Enrico Weigelt, metux IT consult
2015-05-28 10:35 ` Philipp Zabel [this message]
2015-03-18 10:22 ` [PATCH v2 3/5] gpu: ipu-v3: Register scaler platform device Philipp Zabel
2015-03-18 10:22 ` [PATCH v2 4/5] [media] imx-ipu: Add ipu media common code Philipp Zabel
2015-03-18 10:22 ` [PATCH v2 5/5] [media] imx-ipu: Add i.MX IPUv3 scaler driver Philipp Zabel
2015-04-10 13:03 ` [PATCH v2 0/5] i.MX5/6 mem2mem scaler Jean-Michel Hautbois
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=1432809329.3228.19.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=hans.verkuil@cisco.com \
--cc=imolton@ad-holdings.co.uk \
--cc=jean-michel.hautbois@veo-labs.com \
--cc=jean-michel.hautbois@vodalys.com \
--cc=k.debski@samsung.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=s.hauer@pengutronix.de \
--cc=slongerbeam@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;
as well as URLs for NNTP newsgroup(s).