From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.forwardemail.net (smtp.forwardemail.net [149.28.215.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 010E91F16B for ; Thu, 7 May 2026 18:14:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=149.28.215.223 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778177692; cv=none; b=IZgW2kSVpMnpns101RLucqE2jvTwsj4v55/pJY46QVsaEmF3e/DSMV6pCPEprnukcZGP260aPmPsD1BjF4yYefnFEJLlwPcy0SQSOjEy6kpLigLXu4VgCvIe6aOurL0MdMCGSS4OZT/fQsTTYhA56ZW9bP8q2wJbOa/tJEAptzE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778177692; c=relaxed/simple; bh=ucMxtmxCbIOfLcY+eCUTfzDb1Lo5Ld798eqlTaqQhYc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OA+hEmX6Q4iFDE1CNBXlpd7QzwGndXaX9s6TaHnnL84rlnC/ivR+pqO4zDlz3KscN2jIpQ91R91VGQx1IrAybA1yW7EQz0cDdcLW7kgSbgvfp0WY/9IcakJ5PbxJTrYNugultqNkWQgvlS4bMyVUWp/I/IwWu9BRk4jBW8JbcbY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=kwiboo.se; spf=pass smtp.mailfrom=fe-bounces.kwiboo.se; dkim=pass (2048-bit key) header.d=kwiboo.se header.i=@kwiboo.se header.b=dKDNhmae; arc=none smtp.client-ip=149.28.215.223 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=kwiboo.se Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fe-bounces.kwiboo.se Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kwiboo.se header.i=@kwiboo.se header.b="dKDNhmae" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kwiboo.se; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: From: References: Cc: To: Subject: MIME-Version: Date: Message-ID; q=dns/txt; s=fe-e1b5cab7be; t=1778177682; bh=cZAoLcKv/IcNdiZDfzcbMbcVDOeuM0B0mAKB2TAuBuA=; b=dKDNhmaeSOVHdSfO2yKIb7HgxzpuJgJzuHpGxqqHKfwltD1Iu6xPe2o3HhELFlSSKGK6X5ltV bilSBlEXezEGjjP23jFVsL0GgV5yhk1rEGjkTJQ5xF7nBEw+/9GGcLw3iWyX6sTscYPFIgD3eV5 LRAPe046HMmQfcSyMP/VE/4pA583MFjGOTv6kaQpRTblH9N7bvPBMtmXqpORzTq3ATjQIiyGVVB qAMyd6RuXkr1HqMkK0S+mqPGNwCLRT2hF3DJ27CA1nRvaNrN1Bya6OYV7nFg3gvGcAg3w+poPnU 0KlAYABWpY/c4cSqR9ejsjQmEUyy4iDqiYoAmLN/S09A== X-Forward-Email-ID: 69fcd3fe717d2f6fd6afcf98 X-Forward-Email-Sender: rfc822; jonas@kwiboo.se, smtp.forwardemail.net, 149.28.215.223 X-Forward-Email-Version: 2.7.7 X-Forward-Email-Website: https://forwardemail.net X-Complaints-To: abuse@forwardemail.net X-Report-Abuse: abuse@forwardemail.net X-Report-Abuse-To: abuse@forwardemail.net Message-ID: Date: Thu, 7 May 2026 20:03:39 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] phy: rockchip: inno-hdmi: Change TMDS rate handling to configure() ops To: Neil Armstrong , Vinod Koul , Heiko Stuebner Cc: "linux-phy@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linux-rockchip@lists.infradead.org" , "linux-kernel@vger.kernel.org" References: <20260503172936.194003-1-jonas@kwiboo.se> <4d77bbef-6350-48e1-93a5-d256fc8bc8cd@linaro.org> Content-Language: en-US From: Jonas Karlman In-Reply-To: <4d77bbef-6350-48e1-93a5-d256fc8bc8cd@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Neil, On 5/6/2026 5:00 PM, Neil Armstrong wrote: > On 5/3/26 19:29, Jonas Karlman wrote: >> The commit 10ed34d6eaaf ("phy: Add HDMI configuration options") >> introduced a way for HDMI PHYs to be configured through the generic >> phy_configure() function. >> >> This driver currently derives the TMDS character rate from the pixel >> clock and the PHY bus width setting. However, no in-tree consumer of >> this PHY has ever called phy_set_bus_width() to change the TMDS rate. >> >> Change the TMDS character rate handling to depend on the configure() ops >> before any PHY consumer needs to configure a TMDS character rate that is >> different from the pixel clock rate. >> >> Signed-off-by: Jonas Karlman >> --- >> A near future drm/rockchip: dw_hdmi: series plans to include a call to >> phy_configure() to configure this HDMI PHYs TMDS character rate. >> --- >> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 30 ++++++++++--------- >> 1 file changed, 16 insertions(+), 14 deletions(-) >> >> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c >> index 1483907413fa..7f0563d4d482 100644 >> --- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c >> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c >> @@ -245,6 +245,7 @@ struct inno_hdmi_phy { >> struct clk *phyclk; >> unsigned long pixclock; >> unsigned long tmdsclock; >> + struct phy_configure_opts_hdmi hdmi_cfg; >> }; >> >> struct pre_pll_config { >> @@ -554,19 +555,10 @@ static inline void inno_update_bits(struct inno_hdmi_phy *inno, u8 reg, >> static unsigned long inno_hdmi_phy_get_tmdsclk(struct inno_hdmi_phy *inno, >> unsigned long rate) >> { >> - int bus_width = phy_get_bus_width(inno->phy); >> - >> - switch (bus_width) { >> - case 4: >> - case 5: >> - case 6: >> - case 10: >> - case 12: >> - case 16: >> - return (u64)rate * bus_width / 8; >> - default: >> - return rate; >> - } >> + if (inno->hdmi_cfg.tmds_char_rate) >> + return inno->hdmi_cfg.tmds_char_rate; >> + >> + return rate; > > Can't you keep both until dw-hdmi calls the configure op ? I probably could, just not sure how much use it will be. I could split the changes in two different patches for a v2 if that is preferred? The only known user that calls phy_set_bus_width() for this PHY are my out-of-tree HDMI 2.0 patches for Rockchip RK3228/RK3328, i.e. those originating from LibreELEC (also carried by other distros), and also the downstream vendor kernel use a different implementation. I am currently re-working those HDMI 2.0 patches, current working tree can be found at [1], where the patch "drm/rockchip: dw_hdmi: configure PHY in atomic_mode_set" [2] adds a call to phy_configure(). That part of the multi-series effort should reach mailing list any day now. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20260430-rk-hdmi-v2/ [2] https://github.com/Kwiboo/linux-rockchip/commit/555dfa562f40d22a63577c746ab42b0ec1f3ebee Regards, Jonas > >> } >> >> static irqreturn_t inno_hdmi_phy_rk3328_hardirq(int irq, void *dev_id) >> @@ -602,6 +594,16 @@ static irqreturn_t inno_hdmi_phy_rk3328_irq(int irq, void *dev_id) >> return IRQ_HANDLED; >> } >> >> +static int inno_hdmi_phy_configure(struct phy *phy, >> + union phy_configure_opts *opts) >> +{ >> + struct inno_hdmi_phy *inno = phy_get_drvdata(phy); >> + >> + inno->hdmi_cfg = opts->hdmi; >> + >> + return 0; >> +} >> + >> static int inno_hdmi_phy_power_on(struct phy *phy) >> { >> struct inno_hdmi_phy *inno = phy_get_drvdata(phy); >> @@ -668,6 +670,7 @@ static int inno_hdmi_phy_power_off(struct phy *phy) >> >> static const struct phy_ops inno_hdmi_phy_ops = { >> .owner = THIS_MODULE, >> + .configure = inno_hdmi_phy_configure, >> .power_on = inno_hdmi_phy_power_on, >> .power_off = inno_hdmi_phy_power_off, >> }; >> @@ -1392,7 +1395,6 @@ static int inno_hdmi_phy_probe(struct platform_device *pdev) >> } >> >> phy_set_drvdata(inno->phy, inno); >> - phy_set_bus_width(inno->phy, 8); >> >> if (inno->plat_data->ops->init) { >> ret = inno->plat_data->ops->init(inno); >