From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5F86EC021AA for ; Mon, 17 Feb 2025 18:22:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iOG62KwiXOkUPPQRKCrLKp8JBzmXfYKjw8MYThxhSNI=; b=aID02h/7ZRoOOt wwDfxtwUv6kcS4wFh9A7EEKry2JPgpFBdKIgiRkHi0DMyIDh7RXRbQi3TiO85eIvH8r3V4/NXsSF2 v3yN5zxw31FQifFTTHOUJW6B0qZ/PcdjhSHZPIBaeMzSJ/Hgp044MYiWxqGpQ3slPqM9r4RSZ+fyf 398lsRcmYBo/14U8ozDhqdMD2Z9SRoQ+R0S85J7Ob50f4VfZ4bIBA29ORv24lR5v9oW2Paf5sBORN j8n+09d54D4nWoanuCzDxBfRxBz/QVGVxIuFq5tnxyr7AuU/poJLFxk36DazGh7VkDVGV5kMccUuv x41CYx0cauHVX/WfGY1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tk5lV-00000005asF-2qfr; Mon, 17 Feb 2025 18:22:45 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tk5kP-00000005aS8-0guW for linux-rockchip@lists.infradead.org; Mon, 17 Feb 2025 18:21:38 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1739816483; cv=none; d=zohomail.com; s=zohoarc; b=FSDI6hvzppjHNfMqf1bT2xk8SDepDX6IlhW1DlUnW+L4T120jQc2hxnAcGk9fmBtj/cqvOW5wzeHuL9dWN1o9PjFGK2pTWnVnRE/NihBgclGYJ1lMrlZuzPBraxUvmxYK+ouYnirdRegEbpiMvj4WgYqZuHZXjfHr88CtnUydHk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1739816483; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=I4gPtRebb+yuMWszCxvF8QdrCp+aDjd19oW25HRljLU=; b=QvDl393MFB0XSQnZisbMFl2vSE/PM+NI1ufAQi+ZRhABgJDY/9R7lQ4RLryknIjHfWW/90k49PS54cMti9svHV0iwmV/KhYoNi4HK1tu2noDHJ2Kb48pff7XIOyXnxv3YevMfSi82bs/Ci37sPV938GnDREMXFQT+2k/ZT0lEeQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=dmitry.osipenko@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1739816483; s=zohomail; d=collabora.com; i=dmitry.osipenko@collabora.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=I4gPtRebb+yuMWszCxvF8QdrCp+aDjd19oW25HRljLU=; b=hUUIdwp3y/ZuPBUCyoodXLwxupQoyW0nbKs1vaVl6D8xA65ZRQ4oJbly2oQnOtL+ 7TyIvhi99nyGGgUtWPmbi6JvVk2rNsEix8U6/nK9wVZK3gl2qSx7MyAo38afKgsOf8S apP+nZkViFrgoiT8W6WR9bTqtlKT6fFo5QverGoQ= Received: by mx.zohomail.com with SMTPS id 1739816481776736.929364556648; Mon, 17 Feb 2025 10:21:21 -0800 (PST) Message-ID: <398cffa8-5463-47ff-bdeb-3f3167b72312@collabora.com> Date: Mon, 17 Feb 2025 21:21:16 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/6] media: platform: synopsys: Add support for HDMI input driver To: Hans Verkuil , Shreeya Patel , Heiko Stuebner , Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley , jose.abreu@synopsys.com, nelson.costa@synopsys.com, shawn.wen@rock-chips.com, nicolas.dufresne@collabora.com, Sebastian Reichel Cc: kernel@collabora.com, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Tim Surber References: <20250215210417.60074-1-dmitry.osipenko@collabora.com> <20250215210417.60074-5-dmitry.osipenko@collabora.com> <110db742-25a0-4f0c-9620-1af8885d6e1c@xs4all.nl> <3d4b1c45-cc00-4714-8582-0848e38c2ec4@collabora.com> <23eacfe3-cf94-45d3-a405-43185ef32512@xs4all.nl> From: Dmitry Osipenko Content-Language: en-US In-Reply-To: <23eacfe3-cf94-45d3-a405-43185ef32512@xs4all.nl> X-ZohoMailClient: External X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250217_102137_278742_3695541B X-CRM114-Status: GOOD ( 20.65 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On 2/17/25 18:44, Hans Verkuil wrote: > On 2/17/25 16:36, Dmitry Osipenko wrote: >> On 2/17/25 11:31, Hans Verkuil wrote: >>> On 15/02/2025 22:04, Dmitry Osipenko wrote: >>>> From: Shreeya Patel >>>> >>>> Add initial support for the Synopsys DesignWare HDMI RX >>>> Controller Driver used by Rockchip RK3588. The driver >>>> supports: >>>> - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz) >>>> - RGB888, YUV422, YUV444 and YCC420 pixel formats >>>> - CEC >>>> - EDID configuration >>>> >>>> The hardware also has Audio and HDCP capabilities, but these are >>>> not yet supported by the driver. >>>> >>>> Co-developed-by: Dingxian Wen >>>> Signed-off-by: Dingxian Wen >>>> Signed-off-by: Shreeya Patel >>>> Signed-off-by: Dmitry Osipenko >>>> --- >>>> drivers/media/platform/Kconfig | 1 + >>>> drivers/media/platform/Makefile | 1 + >>>> drivers/media/platform/synopsys/Kconfig | 3 + >>>> drivers/media/platform/synopsys/Makefile | 2 + >>>> .../media/platform/synopsys/hdmirx/Kconfig | 27 + >>>> .../media/platform/synopsys/hdmirx/Makefile | 4 + >>>> .../platform/synopsys/hdmirx/snps_hdmirx.c | 2715 +++++++++++++++++ >>>> .../platform/synopsys/hdmirx/snps_hdmirx.h | 394 +++ >>>> .../synopsys/hdmirx/snps_hdmirx_cec.c | 284 ++ >>>> .../synopsys/hdmirx/snps_hdmirx_cec.h | 44 + >>>> 10 files changed, 3475 insertions(+) >>>> create mode 100644 drivers/media/platform/synopsys/Kconfig >>>> create mode 100644 drivers/media/platform/synopsys/Makefile >>>> create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig >>>> create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile >>>> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c >>>> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h >>>> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c >>>> create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h >>>> >>> >>> >>> >>>> +static ssize_t >>>> +hdmirx_debugfs_if_read(u32 type, void *priv, struct file *filp, >>>> + char __user *ubuf, size_t count, loff_t *ppos) >>>> +{ >>>> + struct snps_hdmirx_dev *hdmirx_dev = priv; >>>> + u8 aviif[3 + 7 * 4]; >>>> + int len; >>>> + >>>> + if (type != V4L2_DEBUGFS_IF_AVI) >>>> + return 0; >>>> + >>>> + hdmirx_read_avi_infoframe(hdmirx_dev, aviif); >>>> + >>>> + len = simple_read_from_buffer(ubuf, count, ppos, >>>> + aviif, ARRAY_SIZE(aviif)); >>>> + >>>> + return len < 0 ? 0 : len; >>>> +} >>> >>> Have you tested this with 'edid-decode -c -I /path/to/avi'? Also test that it is >>> empty if there is no AVI InfoFrame (e.g. when there is no incoming video). I don't see >>> a test for that in the code. >>> >>> I also see no sanity check regarding the length of the InfoFrame, it just outputs >>> the full array, meaning you get padding as well since the AVI InfoFrame is smaller >>> than ARRAY_SIZE(aviif). In fact, edid-decode will fail about that if the -c option >>> is used. >>> >>> See tc358743_debugfs_if_read of how this is typically handled. >> >> I've tested with 'edid-decode -I /path/to/avi', including the empty AVI >> InfoFrame. But without the '-c option'. I'd expect that debugfs should >> provide a full-sized raw InfoFrame data, rather than a parsed version. >> The parsed data isn't much useful for debugging purposes, IMO. I >> intentionally removed the size check that tc358743_debugfs_if_read does >> because it appeared wrong to me. Will re-check with '-c option', thanks! > > The HDMI header contains the actual length that was received. So debugfs should > export the actual payload, not the maximum possible payload. > > It is common for hardware to reserve room in the register map for the maximum > payload, but you only want to export what was actually received. If payload is corrupted, it should be handy to see a full payload. Otherwise you won't be able to debug anything because driver returns zero payload to userspace since it can't parse the header :) -- Best regards, Dmitry _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip