All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>,
	niklas.soderlund@ragnatech.se
Cc: linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	magnus.damm@gmail.com, laurent.pinchart@ideasonboard.com,
	ian.molton@codethink.co.uk, lars@metafoo.de,
	william.towle@codethink.co.uk
Subject: Re: [PATCH v3 6/7] media: rcar-vin: initialize EDID data
Date: Mon, 18 Apr 2016 12:13:04 +0200	[thread overview]
Message-ID: <5714B330.9050801@xs4all.nl> (raw)
In-Reply-To: <1460650670-20849-7-git-send-email-ulrich.hecht+renesas@gmail.com>

On 04/14/2016 06:17 PM, Ulrich Hecht wrote:
> Initializes the decoder subdevice with a fixed EDID blob.
> 
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> ---
>  drivers/media/platform/rcar-vin/rcar-v4l2.c | 46 +++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> index ba2ed4e..5b32105 100644
> --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
> +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
> @@ -720,6 +720,41 @@ void rvin_v4l2_remove(struct rvin_dev *vin)
>  	video_unregister_device(&vin->vdev);
>  }
>  
> +static u8 edid[256] = {
> +	0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
> +	0x48, 0xAE, 0x9C, 0x27, 0x00, 0x00, 0x00, 0x00,
> +	0x19, 0x12, 0x01, 0x03, 0x80, 0x00, 0x00, 0x78,
> +	0x0E, 0x00, 0xB2, 0xA0, 0x57, 0x49, 0x9B, 0x26,
> +	0x10, 0x48, 0x4F, 0x2F, 0xCF, 0x00, 0x31, 0x59,
> +	0x45, 0x59, 0x61, 0x59, 0x81, 0x99, 0x01, 0x01,
> +	0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A,
> +	0x80, 0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C,
> +	0x46, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1E,
> +	0x00, 0x00, 0x00, 0xFD, 0x00, 0x31, 0x55, 0x18,
> +	0x5E, 0x11, 0x00, 0x0A, 0x20, 0x20, 0x20, 0x20,
> +	0x20, 0x20, 0x00, 0x00, 0x00, 0xFC, 0x00, 0x43,
> +	0x20, 0x39, 0x30, 0x0A, 0x0A, 0x0A, 0x0A, 0x0A,
> +	0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68,
> +	0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04,
> +	0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07,
> +	0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2,
> +	0x00, 0x2a, 0x01, 0x1d, 0x00, 0x80, 0x51, 0xd0,
> +	0x1c, 0x20, 0x40, 0x80, 0x35, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x1e, 0x8c, 0x0a, 0xd0, 0x8a,
> +	0x20, 0xe0, 0x2d, 0x10, 0x10, 0x3e, 0x96, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xd7
> +};

Where does this EDID come from? I'm just wondering if it has been
adjusted for the capabilities of the adv.

BTW, it is useful if userspace can read the EDID via VIDIOC_G_EDID.

In general I am of two minds whether the EDID should be set in the driver
or whether it should be left to userspace. The EDID contains vendor IDs
and things like that, which are generally better left to userspace for
embedded systems.

Note that the v4l2-ctl utility has support to fill the edid to a standard HDMI
EDID. See v4l2-ctl --help-edid.

My feeling is that it is better to add G/S_EDID support to the r-car driver
and not initialize the EDID at all.

Regards,

	Hans

> +
>  int rvin_v4l2_probe(struct rvin_dev *vin)
>  {
>  	struct v4l2_subdev_format fmt = {
> @@ -821,5 +856,16 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
>  	v4l2_info(&vin->v4l2_dev, "Device registered as %s\n",
>  		  video_device_node_name(&vin->vdev));
>  
> +	{
> +		struct v4l2_subdev_edid rvin_edid = {
> +			.pad = 0,
> +			.start_block = 0,
> +			.blocks = 2,
> +			.edid = edid,
> +		};
> +		v4l2_subdev_call(sd, pad, set_edid,
> +				&rvin_edid);
> +	}
> +
>  	return ret;
>  }
> 


  reply	other threads:[~2016-04-18 10:13 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 16:17 [PATCH v3 0/7] Lager board HDMI input support Ulrich Hecht
2016-04-14 16:17 ` [PATCH v3 1/7] v4l: subdev: Add pad config allocator and init Ulrich Hecht
2016-04-14 16:17 ` [PATCH v3 2/7] media: adv7604: automatic "default-input" selection Ulrich Hecht
2016-04-14 16:17 ` [PATCH v3 3/7] media: rcar_vin: Use correct pad number in try_fmt Ulrich Hecht
2016-04-14 16:17 ` [PATCH v3 5/7] media: rcar-vin: add DV timings support Ulrich Hecht
2016-04-18 10:04   ` Hans Verkuil
2016-04-20 16:24     ` Ulrich Hecht
2016-04-22 12:05       ` Hans Verkuil
2016-04-22 12:37   ` Hans Verkuil
2016-04-22 14:07   ` Hans Verkuil
2016-04-14 16:17 ` [PATCH v3 6/7] media: rcar-vin: initialize EDID data Ulrich Hecht
2016-04-18 10:13   ` Hans Verkuil [this message]
2016-04-20 16:24     ` Ulrich Hecht
2016-04-27  4:06 ` [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.7 Simon Horman
2016-04-27  4:06   ` Simon Horman
2016-04-27  4:06   ` [PATCH 1/4] arm64: dts: r8a7795: Add PCIe nodes Simon Horman
2016-04-27  4:06     ` Simon Horman
2016-04-27  4:06   ` [PATCH 2/4] arm64: dts: r8a7795: enable PCIe on Salvator-X Simon Horman
2016-04-27  4:06     ` Simon Horman
2016-04-27  4:06   ` [PATCH 3/4] arm64: dts: salvator-x: populate EXTALR Simon Horman
2016-04-27  4:06     ` Simon Horman
2016-04-27  4:06   ` [PATCH 4/4] arm64: dts: r8a7795: Don't disable referenced optional clocks Simon Horman
2016-04-27  4:06     ` Simon Horman
2016-04-14 16:17     ` [PATCH v3 4/7] media: rcar-vin: pad-aware driver initialisation, " Ulrich Hecht, Simon Horman
2016-04-14 16:17       ` [PATCH v3 4/7] media: rcar-vin: pad-aware driver initialisation Ulrich Hecht
2016-04-28 14:14   ` [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.7 Arnd Bergmann
2016-04-28 14:14     ` Arnd Bergmann
2016-04-28 14:19     ` Arnd Bergmann
2016-04-28 14:19       ` Arnd Bergmann
2016-04-27  4:20 ` [GIT PULL] Renesas ARM64 Based SoC DT PM Domain " Simon Horman
2016-04-27  4:20   ` Simon Horman
2016-04-27  4:20   ` [PATCH 1/2] arm64: dts: r8a7795: Add SYSC PM Domains Simon Horman
2016-04-27  4:20     ` Simon Horman
2016-04-27  4:20   ` [PATCH 2/2] arm64: dts: r8a7795: Use SYSC "always-on" PM Domain Simon Horman
2016-04-27  4:20     ` Simon Horman
2016-04-14 16:17     ` [PATCH v3 7/7] ARM: dts: lager: Add entries for VIN HDMI input support, " Ulrich Hecht, Simon Horman
2016-04-14 16:17       ` [PATCH v3 7/7] ARM: dts: lager: Add entries for VIN HDMI input support Ulrich Hecht
2016-05-06  0:21   ` [GIT PULL] Renesas ARM64 Based SoC DT PM Domain Updates for v4.7 Simon Horman
2016-05-06  0:21     ` Simon Horman
2016-05-09 13:10     ` Arnd Bergmann
2016-05-09 13:10       ` Arnd Bergmann
2016-05-10  0:03       ` Simon Horman
2016-05-10  0:03         ` Simon Horman
2016-05-09 13:40   ` Arnd Bergmann
2016-05-09 13:40     ` Arnd Bergmann

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=5714B330.9050801@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=ian.molton@codethink.co.uk \
    --cc=lars@metafoo.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=ulrich.hecht+renesas@gmail.com \
    --cc=william.towle@codethink.co.uk \
    /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.