| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <201a9bb7732d51f4807b3b3644e91333f1b746d6.camel@icenowy.me>
Date: Tue, 23 Sep 2025 09:30:05 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie
<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Drew Fustini <fustini@...nel.org>, Guo Ren
<guoren@...nel.org>, Fu Wei <wefu@...hat.com>, Philipp Zabel
<p.zabel@...gutronix.de>, Heiko Stuebner <heiko@...ech.de>, Andrzej Hajda
<andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>, Laurent Pinchart
<Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>, Michal Wilczynski
<m.wilczynski@...sung.com>, Han Gao <rabenda.cn@...il.com>, Yao Zi
<ziyao@...root.org>, dri-devel@...ts.freedesktop.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 5/8] drm/bridge: add a driver for T-Head TH1520 HDMI
controller
在 2025-09-23星期二的 09:11 +0800，Icenowy Zheng写道：
> 在 2025-09-23星期二的 04:00 +0300，Dmitry Baryshkov写道：
> > On Sun, Sep 21, 2025 at 04:34:43PM +0800, Icenowy Zheng wrote:
> > > T-Head TH1520 SoC contains a Synopsys DesignWare HDMI controller
> > > (paired
> > > with DesignWare HDMI TX PHY Gen2) that takes the "DP" output from
> > > the
> > > display controller.
> > >
> > > Add a driver for this controller utilizing the common DesignWare
> > > HDMI
> > > code in the kernel.
> > >
> > > Signed-off-by: Icenowy Zheng <uwu@...nowy.me>
> > > ---
> > > Changes in v2:
> > > - Created a new function to set PHY parameters and refactored the
> > > control flow of the configure_phy callback.
> > >
> > > MAINTAINERS | 1 +
> > > drivers/gpu/drm/bridge/Kconfig | 10 ++
> > > drivers/gpu/drm/bridge/Makefile | 1 +
> > > drivers/gpu/drm/bridge/th1520-dw-hdmi.c | 173
> > > ++++++++++++++++++++++++
> > > 4 files changed, 185 insertions(+)
> > > create mode 100644 drivers/gpu/drm/bridge/th1520-dw-hdmi.c
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index f6206963efbf0..98af9dd3664f5 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -21759,6 +21759,7 @@
> > > F: Documentation/devicetree/bindings/reset/thead,th1520-
> > > reset.yaml
> > > F: arch/riscv/boot/dts/thead/
> > > F: drivers/clk/thead/clk-th1520-ap.c
> > > F: drivers/firmware/thead,th1520-aon.c
> > > +F: drivers/gpu/drm/bridge/th1520-dw-hdmi.c
> > > F: drivers/mailbox/mailbox-th1520.c
> > > F: drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c
> > > F: drivers/pinctrl/pinctrl-th1520.c
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index b9e0ca85226a6..f75e6ad04179f 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -322,6 +322,16 @@ config DRM_THINE_THC63LVD1024
> > > help
> > > Thine THC63LVD1024 LVDS/parallel converter driver.
> > >
> > > +config DRM_THEAD_TH1520_DW_HDMI
> > > + tristate "T-Head TH1520 DesignWare HDMI bridge"
> > > + depends on OF
> > > + depends on COMMON_CLK
> > > + depends on ARCH_THEAD || COMPILE_TEST
> > > + select DRM_DW_HDMI
> > > + help
> > > + Choose this to enable support for the internal HDMI
> > > bridge found
> > > + on the T-Head TH1520 SoC.
> > > +
> > > config DRM_TOSHIBA_TC358762
> > > tristate "TC358762 DSI/DPI bridge"
> > > depends on OF
> > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > b/drivers/gpu/drm/bridge/Makefile
> > > index 245e8a27e3fc5..421e445ff1cd9 100644
> > > --- a/drivers/gpu/drm/bridge/Makefile
> > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > @@ -27,6 +27,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> > > obj-$(CONFIG_DRM_SII902X) += sii902x.o
> > > obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > > obj-$(CONFIG_DRM_SIMPLE_BRIDGE) += simple-bridge.o
> > > +obj-$(CONFIG_DRM_THEAD_TH1520_DW_HDMI) += th1520-dw-hdmi.o
> > > obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> > > obj-$(CONFIG_DRM_TOSHIBA_TC358762) += tc358762.o
> > > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
> > > diff --git a/drivers/gpu/drm/bridge/th1520-dw-hdmi.c
> > > b/drivers/gpu/drm/bridge/th1520-dw-hdmi.c
> > > new file mode 100644
> > > index 0000000000000..efb27d37ff652
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/th1520-dw-hdmi.c
> > > @@ -0,0 +1,173 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2025 Icenowy Zheng <uwu@...nowy.me>
> > > + *
> > > + * Based on rcar_dw_hdmi.c, which is:
> > > + * Copyright (C) 2016 Renesas Electronics Corporation
> > > + * Based on imx8mp-hdmi-tx.c, which is:
> > > + * Copyright (C) 2022 Pengutronix, Lucas Stach
> > > <kernel@...gutronix.de>
> > > + */
> > > +
> > > +#include <linux/clk.h>
> > > +#include <linux/mod_devicetable.h>
> > > +#include <linux/module.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/reset.h>
> > > +
> > > +#include <drm/bridge/dw_hdmi.h>
> > > +#include <drm/drm_modes.h>
> > > +
> > > +#define TH1520_HDMI_PHY_OPMODE_PLLCFG 0x06 /* Mode of
> > > operation and PLL dividers */
> > > +#define TH1520_HDMI_PHY_CKSYMTXCTRL 0x09 /* Clock Symbol
> > > and
> > > Transmitter Control Register */
> > > +#define TH1520_HDMI_PHY_VLEVCTRL 0x0e /* Voltage Level
> > > Control Register */
> > > +#define TH1520_HDMI_PHY_PLLCURRGMPCTRL 0x10 /* PLL current
> > > and
> > > Gmp (conductance) */
> > > +#define TH1520_HDMI_PHY_PLLDIVCTRL 0x11 /* PLL dividers
> > > */
> > > +#define TH1520_HDMI_PHY_TXTERM 0x19 /* Transmission
> > > Termination Register */
> > > +
> > > +struct th1520_hdmi_phy_params {
> > > + unsigned long mpixelclock;
> > > + u16 opmode_pllcfg;
> > > + u16 pllcurrgmpctrl;
> > > + u16 plldivctrl;
> > > + u16 cksymtxctrl;
> > > + u16 vlevctrl;
> > > + u16 txterm;
> > > +};
> > > +
> > > +static const struct th1520_hdmi_phy_params
> > > th1520_hdmi_phy_params[] = {
> > > + { 35500000, 0x0003, 0x0283, 0x0628, 0x8088, 0x01a0,
> > > 0x0007
> > > },
> > > + { 44900000, 0x0003, 0x0285, 0x0228, 0x8088, 0x01a0,
> > > 0x0007
> > > },
> > > + { 71000000, 0x0002, 0x1183, 0x0614, 0x8088, 0x01a0,
> > > 0x0007
> > > },
> > > + { 90000000, 0x0002, 0x1142, 0x0214, 0x8088, 0x01a0,
> > > 0x0007
> > > },
> > > + { 121750000, 0x0001, 0x20c0, 0x060a, 0x8088, 0x01a0,
> > > 0x0007
> > > },
> > > + { 165000000, 0x0001, 0x2080, 0x020a, 0x8088, 0x01a0,
> > > 0x0007
> > > },
> > > + { 198000000, 0x0000, 0x3040, 0x0605, 0x83c8, 0x0120,
> > > 0x0004
> > > },
> > > + { 297000000, 0x0000, 0x3041, 0x0205, 0x81dc, 0x0200,
> > > 0x0005
> > > },
> > > + { 371250000, 0x0640, 0x3041, 0x0205, 0x80f6, 0x0140,
> > > 0x0000
> > > },
> > > + { 495000000, 0x0640, 0x3080, 0x0005, 0x80f6, 0x0140,
> > > 0x0000
> > > },
> > > + { 594000000, 0x0640, 0x3080, 0x0005, 0x80fa, 0x01e0,
> > > 0x0004
> > > },
> > > +};
> > > +
> > > +struct th1520_hdmi {
> > > + struct dw_hdmi_plat_data plat_data;
> > > + struct dw_hdmi *dw_hdmi;
> > > + struct clk *pixclk;
> > > + struct reset_control *mainrst, *prst;
> > > +};
> > > +
> > > +static enum drm_mode_status
> > > +th1520_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
> > > + const struct drm_display_info *info,
> > > + const struct drm_display_mode *mode)
> > > +{
> > > + /*
> > > + * The maximum supported clock frequency is 594 MHz, as
> > > shown in the PHY
> > > + * parameters table.
> > > + */
> > > + if (mode->clock > 594000)
> > > + return MODE_CLOCK_HIGH;
> >
> > Is it the limitation for the pixel clock or for the TMDS char clock
> > (the
> > difference makes sense for non-8-bpc modes.
>
> I have no idea, the BSP driver didn't consider non-8bpc modes, and I
> have no non-8bpc devices to test.
Should I reject non-8bpc modes here because of lack of information?
>
> >
> > > +
> > > + return MODE_OK;
> > > +}
> > > +
> >
>
Powered by blists - more mailing lists