[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 19:54 schrieb Robert Schwebel: >> By the way: i still have some your older patches (2012) in my tree, >> eg. some mediabus, camara, display timing stuff, etc ... not sure >> whether I really need them for my device. >> >> Should I post them to linux-media list for review? > > No. That's all old stuff and has developed quite a lot since then. We'll > post new series here on the lists when they are ready for mainline. Great :) Do you have them on some public repo, so I can give 'em a try ? --mtx -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlieÃlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
On Thu, May 28, 2015 at 07:38:20PM +0200, Enrico Weigelt, metux IT consult wrote: > Thx. already integrated it into my tree - works fine :) > > By the way: i still have some your older patches (2012) in my tree, > eg. some mediabus, camara, display timing stuff, etc ... not sure > whether I really need them for my device. > > Should I post them to linux-media list for review? No. That's all old stuff and has developed quite a lot since then. We'll post new series here on the lists when they are ready for mainline. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 13:59 schrieb Philipp Zabel: >> Where can I get the recent ones ? >> Could you push it to your public repo ? > > I've updated the tmp/imx-ipu-scaler branch. Thx. already integrated it into my tree - works fine :) By the way: i still have some your older patches (2012) in my tree, eg. some mediabus, camara, display timing stuff, etc ... not sure whether I really need them for my device. Should I post them to linux-media list for review ? Oh, and I also still have your famous DRM_IOCTL_MODE_MAP_DUMB hack (the "Reluctantly-signed-off-by:" one ;-), meanwhile rebased / adapted into 4.x. Do you have any idea, what the amd-gpu driver/library exactly does with the retrieved address ? Send it directly to the gpu ? > That should be capture-io-mode=dmabuf for the decoder and > output-io-mode=dmabuf-import for the converter element. h264parse > doesn't provide and fbdevsink can't handle dmabufs, so the decoder's > output-io-mode and the converter's capture-io-mode should be kept as > mmio. I played around a little bit - this command line only takes 55% cpu: gst-launch-1.0 filesrc location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec output-io-mode=4 capture-io-mode=4 \! v4l2 video0convert capture-io-mode=4 output-io-mode=5 \! fbdevsink By the way: what's the exact difference between dmabuf and dmabuf-import ? > > By the way: do you have any idea whether the proprietary driver > > (or the gpus itself) might talk to ipu and vpu ? > > Not that I am aware of. Well, you perhaps can imagine - I dont trust these guys ... --mtx ps: greetings from Bene ... you won't guess where I met him last weekend ;-) -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlieÃlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am Donnerstag, den 28.05.2015, 13:31 +0200 schrieb Enrico Weigelt, metux IT consult: > Am 28.05.2015 um 12:44 schrieb Philipp Zabel: > > Hi, > > >> Are these patches same as in your git branch tmp/imx-ipu-scaler ? > > > > No, that is an older version. > > Where can I get the recent ones ? > Could you push it to your public repo ? I've updated the tmp/imx-ipu-scaler branch. > >> when using it w/ gst for video playback, can be directly pass buffers > >> between VPU, IPU and FB (or let them directly write into shared > >> buffers), so CPU doesn't need to act on each frame for each step > >> in the decoding pipeline ? > > > > Check out the (capture/output-)io-mode parameters, that's what the > > dmabuf/dmabuf-import option pairs are for. > > Tried dmabuf, but load stays at the same (77..80% CPU, 1.2 loadavg). > dmabuf-import doesnt run at all: > > root at KoMo:/usr/share/videos/komo gst-launch-1.0 filesrc > location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec > output-io-mode=5 \! v4l2video0convert capture-io-mode=5 output-io-mode=4 > \! fbdevsink That should be capture-io-mode=dmabuf for the decoder and output-io-mode=dmabuf-import for the converter element. h264parse doesn't provide and fbdevsink can't handle dmabufs, so the decoder's output-io-mode and the converter's capture-io-mode should be kept as mmio. [...] > By the way: do you have any idea whether the proprietary driver > (or the gpus itself) might talk to ipu and vpu ? Not that I am aware of. regards Philipp
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 28.05.2015 um 12:44 schrieb Philipp Zabel: Hi, >> Are these patches same as in your git branch tmp/imx-ipu-scaler ? > > No, that is an older version. Where can I get the recent ones ? Could you push it to your public repo ? >> when using it w/ gst for video playback, can be directly pass buffers >> between VPU, IPU and FB (or let them directly write into shared >> buffers), so CPU doesn't need to act on each frame for each step >> in the decoding pipeline ? > > Check out the (capture/output-)io-mode parameters, that's what the > dmabuf/dmabuf-import option pairs are for. Tried dmabuf, but load stays at the same (77..80% CPU, 1.2 loadavg). dmabuf-import doesnt run at all: root at KoMo:/usr/share/videos/komo gst-launch-1.0 filesrc location=montage.mp4 \! qtdemux \! h264parse \! v4l2video4dec output-io-mode=5 \! v4l2video0convert capture-io-mode=5 output-io-mode=4 \! fbdevsink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: No downstream pool to import from. Additional debug info: gstv4l2object.c(3441): gst_v4l2_object_decide_allocation (): /GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0: When importing DMABUF or USERPTR, we need a pool to import from ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Perhaps not implemented yet in the old version of the patches ? By the way: do you have any idea whether the proprietary driver (or the gpus itself) might talk to ipu and vpu ? cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlieÃlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Hi Enrico, Am Donnerstag, den 28.05.2015, 11:00 +0200 schrieb Enrico Weigelt, metux IT consult: > Am 27.05.2015 um 20:42 schrieb Jean-Michel Hautbois: > > > > @Phillip, > > I've missed the previous mails (just subscribed here yesterday) ... > > Are these patches same as in your git branch tmp/imx-ipu-scaler ? No, that is an older version. > I've got them running on 4.0.4 and currently trying on 4.1-rc* > > Yet another question: > > when using it w/ gst for video playback, can be directly pass buffers > between VPU, IPU and FB (or let them directly write into shared > buffers), so CPU doesn't need to act on each frame for each step > in the decoding pipeline ? Check out the (capture/output-)io-mode parameters, that's what the dmabuf/dmabuf-import option pairs are for. regards Philipp
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
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
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Am 27.05.2015 um 20:42 schrieb Jean-Michel Hautbois: @Phillip, I've missed the previous mails (just subscribed here yesterday) ... Are these patches same as in your git branch tmp/imx-ipu-scaler ? I've got them running on 4.0.4 and currently trying on 4.1-rc* Yet another question: when using it w/ gst for video playback, can be directly pass buffers between VPU, IPU and FB (or let them directly write into shared buffers), so CPU doesn't need to act on each frame for each step in the decoding pipeline ? Playing an 800x400 mp4 still produces about 70..75%. cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlieÃlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Hi Philipp, Lucas and Sascha,
Thanks for that patch series.
2015-03-18 11:22 GMT+01:00 Philipp Zabel :
>
> This patch adds support for mem2mem scaling and colorspace conversion
> using the IC module's post-processing task.
>
> Scaling images larger than 1024x1024 is supported by tiling over multiple
> IC scaling runs. Since the IDMAC and IC units have interesting and different
> alignment limitations for buffer base addresses (left edges) and burst size
> (row lengths), depending on input and output pixel formats, the tile
> rectangles
> and scaling coefficients are chosen to minimize distortion. Due to possible
> overlap, the tiles have to be rendered right to left and bottom to top.
> Up to 7 pixels (depending on frame sizes and scaling factor) have to be
> available after the end of the frame if the width is not burst size aligned.
> 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" ?
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Lucas Stach
> Signed-off-by: Philipp Zabel
> ---
> Changes since v1:
> - Removed deinterlacer support left-overs
> ---
> drivers/gpu/ipu-v3/ipu-ic.c | 787
> +++-
> include/video/imx-ipu-v3.h | 34 +-
> 2 files changed, 804 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index ad75588..984f68f 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "ipu-prv.h"
> @@ -96,6 +97,15 @@ struct ic_task_bitfields {
> u32 ic_cmb_galpha_bit;
> };
>
> +struct ic_task_channels {
> + u8 in;
> + u8 out;
> + u8 rot_in;
> + u8 rot_out;
> + u8 in_prev;
> + u8 in_next;
> +};
> +
> static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
> [IC_TASK_ENCODER] = {
> .rsc = IC_PRP_ENC_RSC,
> @@ -138,12 +148,53 @@ static const struct ic_task_bitfields
> ic_task_bit[IC_NUM_TASKS] = {
> },
> };
>
> +static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
> + [IC_TASK_ENCODER] = {
> + .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
> + .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
> + .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
> + },
> + [IC_TASK_VIEWFINDER] = {
> + .in = IPUV3_CHANNEL_MEM_VDI_CUR,
> + .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_VF,
> + .rot_out = IPUV3_CHANNEL_ROT_VF_MEM,
> + .in_prev = IPUV3_CHANNEL_MEM_VDI_PREV,
> + .in_next = IPUV3_CHANNEL_MEM_VDI_NEXT,
> + },
> + [IC_TASK_POST_PROCESSOR] = {
> + .in = IPUV3_CHANNEL_MEM_IC_PP,
> + .out = IPUV3_CHANNEL_IC_PP_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_PP,
> + .rot_out = IPUV3_CHANNEL_ROT_PP_MEM,
> + },
> +};
> +
> +struct image_convert_ctx {
> + void (*complete)(void *ctx, int err);
> + void *complete_context;
> +
> + struct list_head list;
> + struct ipu_image in;
> + struct ipu_image in_n;
> + struct ipu_image in_p;
> + struct ipu_image out;
> +
> + void *freep;
> +
> + bool rotate:1;
> +
> + u32 rsc;
> +};
> +
> struct ipu_ic_priv;
>
> struct ipu_ic {
> enum ipu_ic_task task;
> const struct ic_task_regoffs *reg;
> const struct ic_task_bitfields *bit;
> + const struct ic_task_channels *ch;
>
> enum ipu_color_space in_cs, g_in_cs;
> enum ipu_color_space out_cs;
> @@ -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 ?
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...
JM
>
>
[PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
This patch adds support for mem2mem scaling and colorspace conversion
using the IC module's post-processing task.
Scaling images larger than 1024x1024 is supported by tiling over multiple
IC scaling runs. Since the IDMAC and IC units have interesting and different
alignment limitations for buffer base addresses (left edges) and burst size
(row lengths), depending on input and output pixel formats, the tile rectangles
and scaling coefficients are chosen to minimize distortion. Due to possible
overlap, the tiles have to be rendered right to left and bottom to top.
Up to 7 pixels (depending on frame sizes and scaling factor) have to be
available after the end of the frame if the width is not burst size aligned.
The tiling code has a parameter to optionally round frame sizes up or down
and avoid overdraw in compositing scenarios.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Removed deinterlacer support left-overs
---
drivers/gpu/ipu-v3/ipu-ic.c | 787 +++-
include/video/imx-ipu-v3.h | 34 +-
2 files changed, 804 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index ad75588..984f68f 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include "ipu-prv.h"
@@ -96,6 +97,15 @@ struct ic_task_bitfields {
u32 ic_cmb_galpha_bit;
};
+struct ic_task_channels {
+ u8 in;
+ u8 out;
+ u8 rot_in;
+ u8 rot_out;
+ u8 in_prev;
+ u8 in_next;
+};
+
static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
[IC_TASK_ENCODER] = {
.rsc = IC_PRP_ENC_RSC,
@@ -138,12 +148,53 @@ static const struct ic_task_bitfields
ic_task_bit[IC_NUM_TASKS] = {
},
};
+static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
+ [IC_TASK_ENCODER] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
+ .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
+ .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
+ },
+ [IC_TASK_VIEWFINDER] = {
+ .in = IPUV3_CHANNEL_MEM_VDI_CUR,
+ .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_VF,
+ .rot_out = IPUV3_CHANNEL_ROT_VF_MEM,
+ .in_prev = IPUV3_CHANNEL_MEM_VDI_PREV,
+ .in_next = IPUV3_CHANNEL_MEM_VDI_NEXT,
+ },
+ [IC_TASK_POST_PROCESSOR] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PP,
+ .out = IPUV3_CHANNEL_IC_PP_MEM,
+ .rot_in = IPUV3_CHANNEL_MEM_ROT_PP,
+ .rot_out = IPUV3_CHANNEL_ROT_PP_MEM,
+ },
+};
+
+struct image_convert_ctx {
+ void (*complete)(void *ctx, int err);
+ void *complete_context;
+
+ struct list_head list;
+ struct ipu_image in;
+ struct ipu_image in_n;
+ struct ipu_image in_p;
+ struct ipu_image out;
+
+ void *freep;
+
+ bool rotate:1;
+
+ u32 rsc;
+};
+
struct ipu_ic_priv;
struct ipu_ic {
enum ipu_ic_task task;
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
+ const struct ic_task_channels *ch;
enum ipu_color_space in_cs, g_in_cs;
enum ipu_color_space out_cs;
@@ -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;
};
struct ipu_ic_priv {
@@ -168,7 +232,8 @@ static inline u32 ipu_ic_read(struct ipu_ic *ic, unsigned
offset)
return readl(ic->priv->base + offset);
}
-static inline void ipu_ic_write(struct ipu_ic *ic, u32 value, unsigned offset)
+static inline void ipu_ic_write(struct ipu_ic *ic, u32 value,
+ unsigned offset)
{
writel(value, ic->priv->base + offset);
}
@@ -446,32 +511,35 @@ int ipu_ic_task_init(struct ipu_ic *ic,
int in_width, int in_height,
int out_width, int out_height,
enum ipu_color_space in_cs,
-enum ipu_color_space out_cs)
+enum ipu_color_space out_cs,
+u32 rsc)
{
struct ipu_ic_priv *priv = ic->priv;
- u32 reg, downsize_coeff, resize_coeff;
+ u32 downsize_coeff, resize_coeff;
unsigned long flags;
int ret = 0;
- /* Setup vertical resizing */
- ret =
