From: Jonas Karlman <jonas@kwiboo.se>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Vinod Koul <vkoul@kernel.org>, Heiko Stuebner <heiko@sntech.de>
Cc: "linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] phy: rockchip: inno-hdmi: Change TMDS rate handling to configure() ops
Date: Thu, 7 May 2026 20:03:39 +0200 [thread overview]
Message-ID: <a9f86194-a96b-4f9b-b8a6-f074e0746dd5@kwiboo.se> (raw)
In-Reply-To: <4d77bbef-6350-48e1-93a5-d256fc8bc8cd@linaro.org>
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 <jonas@kwiboo.se>
>> ---
>> 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);
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
prev parent reply other threads:[~2026-05-07 18:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 17:29 [PATCH] phy: rockchip: inno-hdmi: Change TMDS rate handling to configure() ops Jonas Karlman
2026-05-06 15:00 ` Neil Armstrong
2026-05-07 18:03 ` Jonas Karlman [this message]
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=a9f86194-a96b-4f9b-b8a6-f074e0746dd5@kwiboo.se \
--to=jonas@kwiboo.se \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=vkoul@kernel.org \
/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