[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aKYFh5YI9j-MHKH4@x1>
Date: Wed, 20 Aug 2025 13:27:35 -0400
From: Brian Masney <bmasney@...hat.com>
To: Vinod Koul <vkoul@...nel.org>
Cc: Kishon Vijay Abraham I <kishon@...nel.org>,
Chun-Kuang Hu <chunkuang.hu@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Chunfeng Yun <chunfeng.yun@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Heiko Stuebner <heiko@...ech.de>, linux-phy@...ts.infradead.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v2 2/9] phy: mediatek: phy-mtk-hdmi-mt2701: convert from
round_rate() to determine_rate()
Hi Vinod,
On Wed, Aug 20, 2025 at 09:59:25PM +0530, Vinod Koul wrote:
> On 10-08-25, 18:45, Brian Masney wrote:
> > The round_rate() clk ops is deprecated, so migrate this driver from
> > round_rate() to determine_rate() using the Coccinelle semantic patch
> > on the cover letter of this series.
> >
> > Signed-off-by: Brian Masney <bmasney@...hat.com>
> > ---
> > drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > index e51b2d13eab473dddace48c75c2a8d73c8c65635..b0b6497e7eedcb6867541b573d22156ded29a4d5 100644
> > --- a/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> > @@ -90,10 +90,10 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
> > usleep_range(80, 100);
> > }
> >
> > -static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > - unsigned long *parent_rate)
> > +static int mtk_hdmi_pll_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > - return rate;
> > + return 0;
>
> This does not sound correct to me? should this not check the requested
> rate?
I can't speak as to whether or not this specific driver should have a
rate check here. I've seen in some other drivers where the specific
frequencies are managed in firmware, and Linux just passes on the rate
request as is.
Some other phy drivers (most notably drivers/gpu/drm/msm/dsi/phy/) only
makes sure that the requested rate is within a min/max range. Assuming
I read this driver's set_rate() correctly, it looks like the min/max
range may be 64-192 MHz. I'm not sure to be honest.
This change keeps the existing behavior of the driver as it is today,
and just migrates off an old API.
Brian
Powered by blists - more mailing lists