From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 1/4] v4l: vsp1: Implement partition algorithm restrictions
Date: Mon, 06 Mar 2017 17:16:58 +0200 [thread overview]
Message-ID: <5537374.FMr42qi89O@avalon> (raw)
In-Reply-To: <87tw772apo.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On Monday 06 Mar 2017 06:17:47 Kuninori Morimoto wrote:
> Hi Laurent, Kieran
>
> >>> Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in RGB24: fail
> >>> Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in RGB24: pass
> >>> Testing SRU-UDS scaling 768x576 - 768x576 - 1024x768 in RGB24: pass
> >>> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1280x960 in RGB24: pass
> >>> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1536x1152 in RGB24: pass
> >>> Testing SRU-UDS scaling 768x576 - 1536x1152 - 2048x1536 in RGB24: pass
> >>> Testing UDS-SRU scaling 768x576 - 640x480 - 640x480 in RGB24: pass
> >>> Testing UDS-SRU scaling 768x576 - 640x480 - 1280x960 in RGB24: pass
> >>> Testing UDS-SRU scaling 768x576 - 768x576 - 768x576 in RGB24: pass
> >>> Testing UDS-SRU scaling 768x576 - 768x576 - 1536x1152 in RGB24: pass
> >>> Testing UDS-SRU scaling 768x576 - 1024x768 - 1024x768 in RGB24: pass
> >>> Testing UDS-SRU scaling 768x576 - 1024x768 - 2048x1536 in RGB24: pass
> >>> Testing SRU-UDS scaling 768x576 - 768x576 - 640x480 in YUV444M: fail
> >>> Testing SRU-UDS scaling 768x576 - 768x576 - 768x576 in YUV444M: pass
> >>> Testing SRU-UDS scaling 768x576 - 768x576 - 1024x768 in YUV444M: pass
> >>> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1280x960 in YUV444M: pass
> >>> Testing SRU-UDS scaling 768x576 - 1536x1152 - 1536x1152 in YUV444M: pass
> >>> Testing SRU-UDS scaling 768x576 - 1536x1152 - 2048x1536 in YUV444M:hangs
> >>> Testing UDS-SRU scaling 768x576 - 640x480 - 640x480 in YUV444M: pass
> >>> Testing UDS-SRU scaling 768x576 - 640x480 - 1280x960 in YUV444M: fail
> >>> Testing UDS-SRU scaling 768x576 - 768x576 - 768x576 in YUV444M: pass
> >>> Testing UDS-SRU scaling 768x576 - 768x576 - 1536x1152 in YUV444M: pass
> >>> Testing UDS-SRU scaling 768x576 - 1024x768 - 1024x768 in YUV444M: pass
> >>> Testing UDS-SRU scaling 768x576 - 1024x768 - 2048x1536 in YUV444M:hangs
> >>
> >> (snip)
> >>
> >>> However, from the above tests it looks like the hardware can live with
> >>> more relaxed restrictions than the ones implemented here. I haven't
> >>> tested all UDS scaling ratios, and certainly not under all memory bus
> >>> load conditions, I might thus be too optimistic. Morimoto-san, would it
> >>> be possible to get more information about this from the hardware team,
> >>> to check whether the above two restrictions need to be honoured, or
> >> whether they come from an older hardware version ?
> >>
> >> I asked it to HW team.
> >> Please wait
>
> I'm still waiting from HW team's response, but can you check
> "32.3.7 Image partition for VSPI processing" on v0.53 datasheet ?
> (v0.53 is for ES2.0, but this chapter should be same for ES1.x / ES2.0)
> You may / may not find something from here
That's very detailed, good job of the documentation writers ! Please thank
them for me if you know who they are :-)
I'm sure we will find useful information there. Kieran, could you please have
a look when you'll be back at the end of this week, and list the points that
you think we don't address correctly yet ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-03-06 15:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 18:19 [PATCH 0/4] vsp1 partition algorithm improvements Kieran Bingham
2016-11-04 18:19 ` [PATCH 1/4] v4l: vsp1: Implement partition algorithm restrictions Kieran Bingham
2017-02-13 19:17 ` Laurent Pinchart
2017-02-14 1:15 ` Kuninori Morimoto
2017-03-01 2:26 ` Kuninori Morimoto
2017-03-06 6:17 ` Kuninori Morimoto
2017-03-06 15:16 ` Laurent Pinchart [this message]
2017-03-06 17:07 ` Kieran Bingham
2017-05-09 15:45 ` Kieran Bingham
2016-11-04 18:19 ` [PATCH 2/4] v4l: vsp1: Move vsp1_video_pipeline_setup_partitions() function Kieran Bingham
2017-02-13 19:23 ` Laurent Pinchart
2016-11-04 18:19 ` [PATCH 3/4] v4l: vsp1: Calculate partition sizes at stream start Kieran Bingham
2017-02-13 21:21 ` Laurent Pinchart
2017-05-08 18:31 ` Kieran Bingham
2016-11-04 18:19 ` [PATCH 4/4] v4l: vsp1: Remove redundant context variables Kieran Bingham
2017-02-13 21:21 ` Laurent Pinchart
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=5537374.FMr42qi89O@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
/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.