From: CK Hu <ck.hu@mediatek.com>
To: wangyan wang <wangyan.wang@mediatek.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>,
srv_heupstream@mediatek.com,
chunhui dai <chunhui.dai@mediatek.com>,
Stephen Boyd <sboyd@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Sean Wang <sean.wang@mediatek.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
David Airlie <airlied@linux.ie>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Colin Ian King <colin.king@canonical.com>,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 1/8] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware
Date: Fri, 22 Mar 2019 14:02:43 +0800 [thread overview]
Message-ID: <1553234563.21474.6.camel@mtksdaap41> (raw)
In-Reply-To: <1553138590.18216.26.camel@mtksdaap41>
Hi, Wangyan:
On Thu, 2019-03-21 at 11:23 +0800, CK Hu wrote:
> Hi, Wangyan:
>
> On Wed, 2019-03-06 at 18:07 +0800, CK Hu wrote:
> > Hi, Wangyan:
> >
> > On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> > > From: chunhui dai <chunhui.dai@mediatek.com>
> > >
> > > Recalculate the rate of this clock, by querying hardware.
> > >
> > > Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
> > > Signed-off-by: wangyan wang <wangyan.wang@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 7 ++----
> > > drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 3 +--
> > > drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 35 ++++++++++++++++++++++++++
> > > drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++++++
> > > 4 files changed, 46 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > index 4ef9c57ffd44..13c5e65b9ead 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> > > @@ -29,12 +29,9 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > > return rate;
> > > }
> > >
> > > -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> > > - unsigned long parent_rate)
> > > +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
> > > {
> > > - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > > -
> > > - return hdmi_phy->pll_rate;
> > > + return readl(hdmi_phy->regs + offset);
Inside mtk_hdmi_pll_recalc_rate(), there is just one function, why not
directly call readl() in the caller function?
> > > }
> > >
> > > void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > index f39b1fc66612..fdad8b17a915 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> > > @@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
> > > unsigned int ibias_up;
> > > };
> > >
> > > +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
> > > void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> > > u32 bits);
> > > void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> > > @@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> > > struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
> > > long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
> > > unsigned long *parent_rate);
> > > -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> > > - unsigned long parent_rate);
> > >
> > > extern struct platform_driver mtk_hdmi_phy_driver;
> > > extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > index fcc42dc6ea7f..b25c9dfc432a 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> > > @@ -153,6 +153,41 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> > > RG_HDMITX_DRV_IBIAS_MASK);
> > > return 0;
> > > }
> > > +static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> > > + unsigned long parent_rate)
> > > +{
> > > + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > > + unsigned long out_rate, val;
> > > +
> > > + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> > > + & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
> > > + switch (val) {
> > > + case 0x00:
> > > + out_rate = parent_rate;
> > > + break;
> > > + case 0x01:
> > > + out_rate = parent_rate / 2;
> > > + break;
> > > + default:
> > > + out_rate = parent_rate / 4;
> > > + break;
> > > + }
> > > +
> > > + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> > > + & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
> > > + out_rate *= (val + 1) * 2;
> > > + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
> > > + & RG_HDMITX_TX_POSDIV_MASK);
> > > +
> > > + out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
> > > +
> > > + if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
> > > + out_rate = out_rate / 5;
> > > +
> >
> > All the register you read here is set in mtk_hdmi_pll_set_rate(), so I
> > think you could determine the out_rate in mtk_hdmi_pll_set_rate().
>
> As offline discuss, you mention that when
> cat /sys/kernel/debug/ckl/clk_summary, mtk_hdmi_pll_recalc_rate() is
> called, so read register to get the real clock. The clk_summary call
> clk_core_get_rate() to get rate, and clk_core_get_rate() would check the
> flag CLK_GET_RATE_NOCACHE to call __clk_recalc_rates(), but mtk_hdmi_phy
> does not have this flag, so this function would not be called when
> clk_summary. So I still think you could determine the out_rate in
> mtk_hdmi_pll_set_rate().
As offline discuss, recalc_rate is defined as follow:
* @recalc_rate Recalculate the rate of this clock, by querying
hardware. The
* parent rate is an input parameter. It is up to the caller to
* ensure that the prepare_mutex is held across this call.
* Returns the calculated rate. Optional, but recommended - if
* this op is not set then clock rate will be initialized to 0.
So it looks that recalc_rate is expected to query hardware to get the
out_rate. So this implementation is OK.
>
> Regards,
> CK
>
> >
> > Regards,
> > CK
> >
> > > + hdmi_phy->pll_rate = out_rate;
I think you don't need to assign hdmi_phy->pll_rate in MT2701 because
it's useless in MT2701.
Regards,
CK
> > > +
> > > + return hdmi_phy->pll_rate;
> > > +}
> > >
> > > static const struct clk_ops mtk_hdmi_phy_pll_ops = {
> > > .prepare = mtk_hdmi_pll_prepare,
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > index ed5916b27658..cb23c1e4692a 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> > > @@ -285,6 +285,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> > > return 0;
> > > }
> > >
> > > +static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> > > + unsigned long parent_rate)
> > > +{
> > > + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> > > +
> > > + return hdmi_phy->pll_rate;
> > > +}
> > > +
> > > static const struct clk_ops mtk_hdmi_phy_pll_ops = {
> > > .prepare = mtk_hdmi_pll_prepare,
> > > .unprepare = mtk_hdmi_pll_unprepare,
> >
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-22 6:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 2:09 [PATCH V6 0/8] make mt7623 clock of hdmi stable wangyan wang
2019-02-25 2:09 ` [PATCH v6 1/8] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware wangyan wang
2019-03-06 10:07 ` CK Hu
2019-03-21 3:23 ` CK Hu
2019-03-22 6:02 ` CK Hu [this message]
2019-02-25 2:09 ` [PATCH V6 2/8] drm/mediatek: move the setting of fixed divider wangyan wang
2019-02-25 2:09 ` [PATCH V6 3/8] drm/mediatek: using different flags of clk for HDMI phy wangyan wang
2019-02-25 2:09 ` [PATCH V6 4/8] drm/mediatek: fix the rate and divder of hdmi phy for MT2701 wangyan wang
2019-02-25 2:09 ` [PATCH V6 5/8] clk: mediatek: add MUX_GATE_FLAGS_2 wangyan wang
2019-02-25 17:19 ` Stephen Boyd
2019-02-25 2:09 ` [PATCH V6 6/8] clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel wangyan wang
2019-02-25 17:19 ` Stephen Boyd
2019-02-25 2:09 ` [PATCH V6 7/8] drm/mediatek: using new factor for tvdpll in MT2701 wangyan wang
2019-02-25 2:09 ` [PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy " wangyan wang
2019-03-06 10:13 ` CK Hu
2019-03-21 5:32 ` CK Hu
2019-03-21 7:20 ` CK Hu
2019-03-06 1:52 ` [PATCH V6 0/8] make mt7623 clock of hdmi stable CK Hu
2019-03-06 9:48 ` CK Hu
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=1553234563.21474.6.camel@mtksdaap41 \
--to=ck.hu@mediatek.com \
--cc=airlied@linux.ie \
--cc=chunhui.dai@mediatek.com \
--cc=colin.king@canonical.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=mturquette@baylibre.com \
--cc=ryder.lee@mediatek.com \
--cc=sboyd@kernel.org \
--cc=sean.wang@mediatek.com \
--cc=srv_heupstream@mediatek.com \
--cc=wangyan.wang@mediatek.com \
/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;
as well as URLs for NNTP newsgroup(s).