[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d41bfc24-2787-4bae-aa8e-352899be097b@collabora.com>
Date: Wed, 5 Mar 2025 14:08:58 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Hans Verkuil <hverkuil@...all.nl>,
Nicolas Dufresne <nicolas.dufresne@...labora.com>,
Shreeya Patel <shreeya.patel@...labora.com>, Heiko Stuebner
<heiko@...ech.de>, Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, jose.abreu@...opsys.com,
nelson.costa@...opsys.com, shawn.wen@...k-chips.com,
Sebastian Reichel <sebastian.reichel@...labora.com>
Cc: kernel@...labora.com, linux-media@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-rockchip@...ts.infradead.org, Tim Surber <me@...surber.de>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>
Subject: Re: [PATCH v10 6/6] arm64: defconfig: Enable Synopsys HDMI receiver
On 3/4/25 19:17, Hans Verkuil wrote:
> On 28/02/2025 04:51, Nicolas Dufresne wrote:
>> Hi Hans,
>>
>> Le mercredi 26 février 2025 à 09:31 +0100, Hans Verkuil a écrit :
>>> On 25/02/2025 19:30, Dmitry Osipenko wrote:
>>>> From: Sebastian Reichel <sebastian.reichel@...labora.com>
>>>>
>>>> The Rockchip RK3588 has a built-in HDMI receiver block from
>>>> Synopsys. Let's enable the driver for it.
>>>>
>>>> Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
>>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@...labora.com>
>>>> ---
>>>> arch/arm64/configs/defconfig | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/configs/defconfig
>>>> b/arch/arm64/configs/defconfig
>>>> index cb7da4415599..3dccc9e1c4aa 100644
>>>> --- a/arch/arm64/configs/defconfig
>>>> +++ b/arch/arm64/configs/defconfig
>>>> @@ -859,6 +859,8 @@ CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
>>>> CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
>>>> CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
>>>> CONFIG_VIDEO_SUN6I_CSI=m
>>>> +CONFIG_VIDEO_SYNOPSYS_HDMIRX=m
>>>> +CONFIG_VIDEO_SYNOPSYS_HDMIRX_LOAD_DEFAULT_EDID=y
>>>
>>> I do not believe it is a good idea to default to y for this option.
>>>
>>> The EDID depends on the specific device you make, and you should
>>> think carefully about whether the default EDID fits the needs of the
>>> device.
>>>
>>> So if you want the default EDID, then you should manually select it
>>> and not have it autoselected.
>>
>> Following up here, from the device maker perspective sure, but I'm not
>> sure this is the best choice for generic Linux distribution. As of
>> today, pretty much no userspace capture software knows about this,
>> meaning the device will not work out of the box in OBS, GStreamer,
>> Ffmpeg, Web Browsers. In comparison, if you pick any UVC HDMI capture,
>> it just work, with a default EDID that covers the range of
>> capabilities, which in this case are defined by the SoC.
>
> A UVC HDMI capture device is not a good comparison: that has it's own
> EDID that is configured for the specific hardware and USB bandwidth
> limitations. EDID handling is all internal to that device, nothing to
> do with the UVC driver.
>
> That said, this device is a bit different compared to most other
> HDMI receivers in that it also has a DMA engine. Usually HDMI receivers
> are i2c devices that connect to an SoC. In this case the hardware is
> inside the SoC. So I am OK with making LOAD_DEFAULT_EDID=y in the defconfig.
>
> So:
>
> Acked-by: Hans Verkuil <hverkuil@...all.nl>
>
> Note that I will merge the v13 driver (patches 1-3), since it looks good.
>
> But v11-v13 of this defconfig patch dropped the "CONFIG_VIDEO_SYNOPSYS_HDMIRX_LOAD_DEFAULT_EDID=y"
> line, so you might want to post a v14 of just patches 4-6, restoring that
> line, once I merged patches 1-3.
Will post v14, thanks!
--
Best regards,
Dmitry
Powered by blists - more mailing lists