From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v2 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances
Date: Thu, 13 Jul 2017 18:49:19 +0100 [thread overview]
Message-ID: <22c14966-67d6-82b2-e305-d371efde0d23@ideasonboard.com> (raw)
In-Reply-To: <20170626181226.29575-9-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On 26/06/17 19:12, Laurent Pinchart wrote:
> New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL,
> as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for
> them in the VSP device info table.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Code in the patch looks OK - but I can't see where the difference between the
horizontal widths are supported between VSPD H3/VC
I see this in the datasheet: (32.1.1.6 in this particular part)
Direct connection to display module
— Supporting 4096 pixels in horizontal direction [R-Car H3/R-Car M3-W/ R-Car M3-N]
— Supporting 2048 pixels in horizontal direction [R-Car V3M/R-Car V3H/R-Car
D3/R-Car E3]
Do we have this information encoded anywhere? or are they just talking about
maximum performance capability there?
Also some features that are implied as supported aren't mentioned - but that's
not a blocker to adding in the initial devices at all.
Therefore:
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> ---
> drivers/media/platform/vsp1/vsp1_drv.c | 24 ++++++++++++++++++++++++
> drivers/media/platform/vsp1/vsp1_regs.h | 15 +++++++++++++--
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c
> index 6a9aeb71aedf..c4f2ac61f7d2 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -710,6 +710,14 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
> .num_bru_inputs = 5,
> .uapi = true,
> }, {
> + .version = VI6_IP_VERSION_MODEL_VSPBS_GEN3,
> + .model = "VSP2-BS",
> + .gen = 3,
> + .features = VSP1_HAS_BRS,
32.1.1.5 implies:
| VSP1_HAS_WPF_VFLIP
But Figure 32.5 implies that it doesn't ...
Figure 32.5 also implies that | VSP1_HAS_CLU is there too on both RPF0, and RPF1
> + .rpf_count = 2,
> + .wpf_count = 1,
> + .uapi = true,
> + }, {
> .version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
> .model = "VSP2-D",
> .gen = 3,
> @@ -717,6 +725,22 @@ static const struct vsp1_device_info vsp1_device_infos[] = {
> .rpf_count = 5,
> .wpf_count = 2,
> .num_bru_inputs = 5,
> + }, {
> + .version = VI6_IP_VERSION_MODEL_VSPD_V3,
> + .model = "VSP2-D",
> + .gen = 3,
> + .features = VSP1_HAS_BRS | VSP1_HAS_BRU | VSP1_HAS_LIF,
> + .rpf_count = 5,
> + .wpf_count = 1,
> + .num_bru_inputs = 5,
> + }, {
> + .version = VI6_IP_VERSION_MODEL_VSPDL_GEN3,
> + .model = "VSP2-DL",
> + .gen = 3,
> + .features = VSP1_HAS_BRS | VSP1_HAS_BRU | VSP1_HAS_LIF,
Hrm. 32.1.1.7 says:
— Vertical flipping in case of output to memory.
So thats some sort of a conditional : | VSP1_HAS_WPF_VFLIP
So looking at this and the settings of the existing models, I guess it looks
like we don't support flip if we have an LIF output (as that would then be
unsupported)
> + .rpf_count = 5,
> + .wpf_count = 2,
> + .num_bru_inputs = 5,
> },
> };
>
> diff --git a/drivers/media/platform/vsp1/vsp1_regs.h b/drivers/media/platform/vsp1/vsp1_regs.h
> index 744217e020b9..ab439a60a100 100644
> --- a/drivers/media/platform/vsp1/vsp1_regs.h
> +++ b/drivers/media/platform/vsp1/vsp1_regs.h
> @@ -699,9 +699,20 @@
> #define VI6_IP_VERSION_MODEL_VSPBD_GEN3 (0x15 << 8)
> #define VI6_IP_VERSION_MODEL_VSPBC_GEN3 (0x16 << 8)
> #define VI6_IP_VERSION_MODEL_VSPD_GEN3 (0x17 << 8)
> +#define VI6_IP_VERSION_MODEL_VSPD_V3 (0x18 << 8)
> +#define VI6_IP_VERSION_MODEL_VSPDL_GEN3 (0x19 << 8)
> +#define VI6_IP_VERSION_MODEL_VSPBS_GEN3 (0x1a << 8)
> #define VI6_IP_VERSION_SOC_MASK (0xff << 0)
> -#define VI6_IP_VERSION_SOC_H (0x01 << 0)
> -#define VI6_IP_VERSION_SOC_M (0x02 << 0)
> +#define VI6_IP_VERSION_SOC_H2 (0x01 << 0)
> +#define VI6_IP_VERSION_SOC_V2H (0x01 << 0)
> +#define VI6_IP_VERSION_SOC_V3M (0x01 << 0)
> +#define VI6_IP_VERSION_SOC_M2 (0x02 << 0)
> +#define VI6_IP_VERSION_SOC_M3W (0x02 << 0)
> +#define VI6_IP_VERSION_SOC_V3H (0x02 << 0)
> +#define VI6_IP_VERSION_SOC_H3 (0x03 << 0)
> +#define VI6_IP_VERSION_SOC_D3 (0x04 << 0)
> +#define VI6_IP_VERSION_SOC_M3N (0x04 << 0)
> +#define VI6_IP_VERSION_SOC_E3 (0x04 << 0)
>
> /* -----------------------------------------------------------------------------
> * RPF CLUT Registers
>
next prev parent reply other threads:[~2017-07-13 17:49 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-26 18:12 [PATCH v2 00/14] Renesas R-Car VSP: Add H3 ES2.0 support Laurent Pinchart
2017-06-26 18:12 ` [PATCH v2 01/14] v4l: vsp1: Fill display list headers without holding dlm spinlock Laurent Pinchart
2017-07-13 12:48 ` Kieran Bingham
2017-07-20 13:50 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 02/14] v4l: vsp1: Don't recycle active list at display start Laurent Pinchart
2017-07-13 17:02 ` Kieran Bingham
2017-07-20 13:51 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 03/14] v4l: vsp1: Don't set WPF sink pointer Laurent Pinchart
2017-07-13 12:50 ` Kieran Bingham
2017-07-20 13:52 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 04/14] v4l: vsp1: Store source and sink pointers as vsp1_entity Laurent Pinchart
2017-07-13 13:00 ` Kieran Bingham
2017-07-20 13:53 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 05/14] v4l: vsp1: Don't create links for DRM pipeline Laurent Pinchart
2017-07-13 13:06 ` Kieran Bingham
2017-07-20 13:54 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 06/14] v4l: vsp1: Add pipe index argument to the VSP-DU API Laurent Pinchart
2017-07-13 13:16 ` Kieran Bingham
2017-07-13 23:04 ` Laurent Pinchart
2017-07-20 13:56 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 07/14] v4l: vsp1: Add support for the BRS entity Laurent Pinchart
2017-07-13 13:38 ` Kieran Bingham
2017-07-20 13:58 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances Laurent Pinchart
2017-07-13 17:49 ` Kieran Bingham [this message]
2017-07-13 23:31 ` Laurent Pinchart
2017-07-14 7:36 ` Kieran Bingham
2017-07-14 0:35 ` [PATCH v2.1 " Laurent Pinchart
2017-07-20 13:59 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 09/14] v4l: vsp1: Add support for multiple LIF instances Laurent Pinchart
2017-07-13 17:57 ` Kieran Bingham
2017-07-20 14:00 ` Mauro Carvalho Chehab
2017-06-26 18:12 ` [PATCH v2 10/14] v4l: vsp1: Add support for multiple DRM pipelines Laurent Pinchart
2017-07-20 14:02 ` Mauro Carvalho Chehab
2017-08-01 18:39 ` Kieran Bingham
2017-06-26 18:12 ` [PATCH v2 11/14] v4l: vsp1: Add support for header display lists in continuous mode Laurent Pinchart
2017-07-20 14:03 ` Mauro Carvalho Chehab
2017-08-01 17:35 ` Kieran Bingham
2017-08-01 18:47 ` Laurent Pinchart
2017-08-02 11:06 ` Kieran Bingham
2017-06-26 18:12 ` [PATCH v2 12/14] drm: rcar-du: Support multiple sources from the same VSP Laurent Pinchart
2017-08-01 18:10 ` Kieran Bingham
2017-08-01 19:01 ` Laurent Pinchart
2017-06-26 18:12 ` [PATCH v2 13/14] drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x Laurent Pinchart
2017-08-01 14:06 ` Kieran Bingham
2017-08-01 18:39 ` Laurent Pinchart
2017-12-11 20:58 ` Laurent Pinchart
2017-06-26 18:12 ` [PATCH v2 14/14] drm: rcar-du: Configure DPAD0 routing through last group on Gen3 Laurent Pinchart
2017-08-01 13:46 ` Kieran Bingham
2017-08-01 13:51 ` Laurent Pinchart
2017-08-01 17:20 ` [PATCH v2.1 " Laurent Pinchart
2017-08-01 17:23 ` Kieran Bingham
2017-07-13 12:25 ` [PATCH v2 00/14] Renesas R-Car VSP: Add H3 ES2.0 support Kieran Bingham
2017-07-14 0:54 ` Laurent Pinchart
2017-07-18 13:03 ` Hans Verkuil
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=22c14966-67d6-82b2-e305-d371efde0d23@ideasonboard.com \
--to=kieran.bingham@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart+renesas@ideasonboard.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 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).