public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: kernel@collabora.com, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	Shreeya Patel <shreeya.patel@collabora.com>,
	heiko@sntech.de, mchehab@kernel.org, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org, mturquette@baylibre.com,
	sboyd@kernel.org, p.zabel@pengutronix.de,
	jose.abreu@synopsys.com, nelson.costa@synopsys.com,
	shawn.wen@rock-chips.com, nicolas.dufresne@collabora.com,
	hverkuil-cisco@xs4all.nl
Subject: Re: [RESEND PATCH v5 4/4] media: platform: synopsys: Add support for HDMI input driver
Date: Tue, 11 Feb 2025 19:02:55 +0300	[thread overview]
Message-ID: <dd41b33d-e73a-4ff8-803f-00a3ab7c9c4b@collabora.com> (raw)
In-Reply-To: <b6ee761c-6941-473b-aa5e-2dadb69767f2@xs4all.nl>

On 2/10/25 16:46, Hans Verkuil wrote:
...
>> +static bool hdmirx_check_timing_valid(struct v4l2_bt_timings *bt)
>> +{
>> +	if (bt->width < 100 || bt->width > 5000 ||
>> +	    bt->height < 100 || bt->height > 5000)
>> +		return false;
>> +
>> +	if (!bt->hsync || bt->hsync > 200 ||
>> +	    !bt->vsync || bt->vsync > 100)
>> +		return false;
>> +
>> +	if (!bt->hbackporch || bt->hbackporch > 2000 ||
>> +	    !bt->vbackporch || bt->vbackporch > 2000)
>> +		return false;
>> +
>> +	if (!bt->hfrontporch || bt->hfrontporch > 2000 ||
>> +	    !bt->vfrontporch || bt->vfrontporch > 2000)
>> +		return false;
> 
> I asked before, but are these hardware limitations or just sanity checks?
> Please document.

These should be sanity checks. We added comment explaining what this
code does, telling that we need to repeat checking the timing values
until they become valid. This is borrowed from downstream driver,
whether these values are tied to hw limits is unknown, we couldn't find
the exact limits documented in TRM.

...
>> +static int hdmirx_set_edid(struct file *file, void *fh, struct v4l2_edid *edid)
>> +{
>> +	struct hdmirx_stream *stream = video_drvdata(file);
>> +	struct snps_hdmirx_dev *hdmirx_dev = stream->hdmirx_dev;
>> +	u16 phys_addr;
>> +	int ret;
>> +
>> +	if (edid->pad)
>> +		return -EINVAL;
>> +
>> +	if (edid->start_block)
>> +		return -EINVAL;
>> +
>> +	if (edid->blocks > EDID_NUM_BLOCKS_MAX) {
>> +		edid->blocks = EDID_NUM_BLOCKS_MAX;
>> +		return -E2BIG;
>> +	}
>> +
>> +	if (!edid->blocks) {
>> +		cec_phys_addr_invalidate(hdmirx_dev->cec->adap);
>> +		hdmirx_dev->edid_blocks_written = 0;
> 
> This must pull the HPD low, but that doesn't happen.

Good catch, will fix.

...
>> +static void hdmirx_get_avi_infoframe(struct snps_hdmirx_dev *hdmirx_dev)
>> +{
>> +	struct v4l2_device *v4l2_dev = &hdmirx_dev->v4l2_dev;
>> +	union hdmi_infoframe frame = {};
>> +	int err, i, b, itr = 0;
>> +	u8 aviif[3 + 7 * 4];
>> +	u32 val;
>> +
>> +	aviif[itr++] = HDMI_INFOFRAME_TYPE_AVI;
>> +	val = hdmirx_readl(hdmirx_dev, PKTDEC_AVIIF_PH2_1);
>> +	aviif[itr++] = val & 0xff;
>> +	aviif[itr++] = (val >> 8) & 0xff;
>> +
>> +	for (i = 0; i < 7; i++) {
>> +		val = hdmirx_readl(hdmirx_dev, PKTDEC_AVIIF_PB3_0 + 4 * i);
>> +
>> +		for (b = 0; b < 4; b++)
>> +			aviif[itr++] = (val >> (8 * b)) & 0xff;
>> +	}
>> +
>> +	err = hdmi_infoframe_unpack(&frame, aviif, sizeof(aviif));
>> +	if (err) {
>> +		v4l2_err(v4l2_dev, "failed to unpack AVI infoframe\n");
>> +		return;
>> +	}
>> +
>> +	v4l2_ctrl_s_ctrl(hdmirx_dev->rgb_range, frame.avi.quantization_range);
>> +
>> +	if (frame.avi.itc)
>> +		v4l2_ctrl_s_ctrl(hdmirx_dev->content_type,
>> +				 frame.avi.content_type);
>> +	else
>> +		v4l2_ctrl_s_ctrl(hdmirx_dev->content_type,
>> +				 V4L2_DV_IT_CONTENT_TYPE_NO_ITC);
> 
> InfoFrames must now also be exported to debugfs. See e.g. drivers/media/i2c/tc358743.c
> and include/media/v4l2-dv-timings.h (search for V4L2_DEBUGFS_IF_MAX_LEN).
> 
> This is a recent change: both drm and v4l2 can now export InfoFrames to debugfs,
> and this is handy for debugging issues.
> 
> The edid-decode utility (part of v4l-utils) can parse these InfoFrames.

Ack, will add the InfoFrame debugfs.

...
>> +static void hdmirx_load_default_edid(struct snps_hdmirx_dev *hdmirx_dev)
>> +{
>> +	struct v4l2_edid def_edid;
>> +
>> +	hdmirx_hpd_ctrl(hdmirx_dev, false);
>> +
>> +	/* disable hpd and write edid */
>> +	def_edid.pad = 0;
>> +	def_edid.start_block = 0;
>> +	def_edid.blocks = EDID_NUM_BLOCKS_MAX;
>> +
>> +	if (IS_ENABLED(CONFIG_VIDEO_SYNOPSYS_HDMIRX_LOAD_DEFAULT_EDID))
>> +		def_edid.edid = edid_default;
>> +	else
>> +		def_edid.edid = hdmirx_dev->edid;
> 
> So if you are not loading the default EDID, then you load a zeroed EDID?
> 
> This is much too complicated: if there is no default EDID, then just
> pull the HPD low (you do that already at the start) and return.
> 
> BTW, please check with CONFIG_VIDEO_SYNOPSYS_HDMIRX_LOAD_DEFAULT_EDID set
> and unset and make sure there are no compile warnings/errors relating to that.

Now I see what you meant previously. Keeping HPD pulled low if there is
no valid EDID will work. Will change it in the next iteration.

Thanks for the review!

-- 
Best regards,
Dmitry

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-02-11 16:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10 19:39 [RESEND PATCH v5 0/4] Add Synopsys DesignWare HDMI RX Controller Shreeya Patel
2024-12-10 19:39 ` [RESEND PATCH v5 1/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver Shreeya Patel
2024-12-10 19:39 ` [RESEND PATCH v5 2/4] dt-bindings: media: Document bindings for HDMI RX Controller Shreeya Patel
2024-12-10 19:39 ` [RESEND PATCH v5 3/4] arm64: dts: rockchip: Add device tree support " Shreeya Patel
2024-12-10 19:39 ` [RESEND PATCH v5 4/4] media: platform: synopsys: Add support for HDMI input driver Shreeya Patel
2025-02-10 13:46   ` Hans Verkuil
2025-02-11 16:02     ` Dmitry Osipenko [this message]
2025-01-06  0:26 ` [RESEND PATCH v5 0/4] Add Synopsys DesignWare HDMI RX Controller Tim Surber
     [not found] ` <acb91a34-c0f8-4f03-8945-755b4e42dcf3@timsurber.de>
2025-01-06 11:22   ` Dmitry Osipenko
2025-01-07  0:08     ` Tim Surber
2025-01-07  7:27       ` Dmitry Osipenko
2025-01-08 23:17         ` Tim Surber
2025-01-14 11:37           ` Dmitry Osipenko
2025-01-14 14:16             ` Nicolas Dufresne
2025-01-19  2:14             ` Tim Surber
2025-01-23 11:21               ` Dmitry Osipenko

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=dd41b33d-e73a-4ff8-803f-00a3ab7c9c4b@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=hverkuil@xs4all.nl \
    --cc=jose.abreu@synopsys.com \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=nelson.costa@synopsys.com \
    --cc=nicolas.dufresne@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=shawn.wen@rock-chips.com \
    --cc=shreeya.patel@collabora.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