All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Liao <jamesjj.liao@mediatek.com>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: "Sascha Hauer" <s.hauer@pengutronix.de>,
	"Heiko Stübner" <heiko@sntech.de>,
	"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
	"Mike Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mediatek@lists.infradead.org, ted.lin@mediatek.com,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Eddie Huang" <eddie.huang@mediatek.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null
Date: Fri, 3 Jul 2015 15:45:12 +0800	[thread overview]
Message-ID: <1435909512.3526.71.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omCk50Q5b=ey5v1z2gha5Ybc+Fus0Ls+S=5n08xu7Svacw@mail.gmail.com>

On Thu, 2015-07-02 at 12:23 +0800, Daniel Kurtz wrote:
> On Thu, Jul 2, 2015 at 11:06 AM, James Liao <jamesjj.liao@mediatek.com> wrote:
> > These clocks such as clkph_mck_o are configured by other modules before
> > kernel init, and their rates may different among platforms.
> 
> What other modules?
> Do you mean the rates are configured by firmware?
> How are the rates set?
> Are there registers that configure its rate?
> If so, why can't the kernel read these registers and compute the current rate?

CLKPH_MCK_O for example, it's a DRAM related clock, and initialized in
preloader (before kernel init). It's setting may be different because
using different DRAM module. And the setting may be changed dynamically
in runtime.

We don't care CLKPH_MCK_O's rate in CCF because we don't need to change
mem_sel's setting in kernel, and there is not driver need to know
mem_sel's rate.

> 
> For mt8173, we are essentially discussing the following clocks (whose
> sole parent is clk_null):
> 
> FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
> GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5),
> GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7),
> GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10),
> GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16),
> GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17),
> 
> clkph_mck_o - This is the parent for dmpll_*, which are themselves
> (potential) parent clocks for nearly every subsystem.
> In fact, as shown above, the dmpll_* is the selected parent for
> several other clocks, which all end up with an unknown rate.
> So, I think it is worth investigating a little more how to properly
> read or otherwise specify the rate for clkph_mck_o.

Please see above.

> dpi_ck, infra_cpum, mm_dsi0_digital, mm_dsi1_digital, mm_lvds_cts -
> These are a dead-end (internal?) clock.
> It is probably fine if their rates are unknown (0 Hz).
> 
> usb_syspll_125m - This sounds like a fixed 125 MHz clock.  It is also
> a possible parent usb30 clock, so its value will propagate.
> 
> hdmitx_dig_cts - This is the root clock for the tree leading to
> mm_hdmi_pllck, which includes hdmitxpll_d* and hdmi_sel.
> However, I don't know how "mm_hdmi_pllck" is used.
> 
> mm_dpi1_pixel, mm_lvds_pixel - These two look very suspicious.  The
> similar "mm_dpi0_pixel" and "mm_hdmi_pixel" have parent dpi0_sel.
> It looks like maybe they should have "dpi1_sel" or "dpilvds_sel" as
> parents, but the _sel are not hooked up.

Subsystem clocks with parent clk_null may have different reasons. I'll
get back to you later.


Best regards,

James






WARNING: multiple messages have this Message-ID (diff)
From: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
To: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: "Sascha Hauer" <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"open list:OPEN FIRMWARE AND..."
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Mike Turquette"
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	"Stephen Boyd" <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	ted.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	"Matthias Brugger"
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"Eddie Huang"
	<eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null
Date: Fri, 3 Jul 2015 15:45:12 +0800	[thread overview]
Message-ID: <1435909512.3526.71.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omCk50Q5b=ey5v1z2gha5Ybc+Fus0Ls+S=5n08xu7Svacw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, 2015-07-02 at 12:23 +0800, Daniel Kurtz wrote:
> On Thu, Jul 2, 2015 at 11:06 AM, James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> > These clocks such as clkph_mck_o are configured by other modules before
> > kernel init, and their rates may different among platforms.
> 
> What other modules?
> Do you mean the rates are configured by firmware?
> How are the rates set?
> Are there registers that configure its rate?
> If so, why can't the kernel read these registers and compute the current rate?

CLKPH_MCK_O for example, it's a DRAM related clock, and initialized in
preloader (before kernel init). It's setting may be different because
using different DRAM module. And the setting may be changed dynamically
in runtime.

We don't care CLKPH_MCK_O's rate in CCF because we don't need to change
mem_sel's setting in kernel, and there is not driver need to know
mem_sel's rate.

> 
> For mt8173, we are essentially discussing the following clocks (whose
> sole parent is clk_null):
> 
> FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
> GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5),
> GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7),
> GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10),
> GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16),
> GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17),
> 
> clkph_mck_o - This is the parent for dmpll_*, which are themselves
> (potential) parent clocks for nearly every subsystem.
> In fact, as shown above, the dmpll_* is the selected parent for
> several other clocks, which all end up with an unknown rate.
> So, I think it is worth investigating a little more how to properly
> read or otherwise specify the rate for clkph_mck_o.

Please see above.

> dpi_ck, infra_cpum, mm_dsi0_digital, mm_dsi1_digital, mm_lvds_cts -
> These are a dead-end (internal?) clock.
> It is probably fine if their rates are unknown (0 Hz).
> 
> usb_syspll_125m - This sounds like a fixed 125 MHz clock.  It is also
> a possible parent usb30 clock, so its value will propagate.
> 
> hdmitx_dig_cts - This is the root clock for the tree leading to
> mm_hdmi_pllck, which includes hdmitxpll_d* and hdmi_sel.
> However, I don't know how "mm_hdmi_pllck" is used.
> 
> mm_dpi1_pixel, mm_lvds_pixel - These two look very suspicious.  The
> similar "mm_dpi0_pixel" and "mm_hdmi_pixel" have parent dpi0_sel.
> It looks like maybe they should have "dpi1_sel" or "dpilvds_sel" as
> parents, but the _sel are not hooked up.

Subsystem clocks with parent clk_null may have different reasons. I'll
get back to you later.


Best regards,

James





--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: jamesjj.liao@mediatek.com (James Liao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: dts: mt8173: add clock_null
Date: Fri, 3 Jul 2015 15:45:12 +0800	[thread overview]
Message-ID: <1435909512.3526.71.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omCk50Q5b=ey5v1z2gha5Ybc+Fus0Ls+S=5n08xu7Svacw@mail.gmail.com>

On Thu, 2015-07-02 at 12:23 +0800, Daniel Kurtz wrote:
> On Thu, Jul 2, 2015 at 11:06 AM, James Liao <jamesjj.liao@mediatek.com> wrote:
> > These clocks such as clkph_mck_o are configured by other modules before
> > kernel init, and their rates may different among platforms.
> 
> What other modules?
> Do you mean the rates are configured by firmware?
> How are the rates set?
> Are there registers that configure its rate?
> If so, why can't the kernel read these registers and compute the current rate?

CLKPH_MCK_O for example, it's a DRAM related clock, and initialized in
preloader (before kernel init). It's setting may be different because
using different DRAM module. And the setting may be changed dynamically
in runtime.

We don't care CLKPH_MCK_O's rate in CCF because we don't need to change
mem_sel's setting in kernel, and there is not driver need to know
mem_sel's rate.

> 
> For mt8173, we are essentially discussing the following clocks (whose
> sole parent is clk_null):
> 
> FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
> GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5),
> GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7),
> GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10),
> GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16),
> GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17),
> 
> clkph_mck_o - This is the parent for dmpll_*, which are themselves
> (potential) parent clocks for nearly every subsystem.
> In fact, as shown above, the dmpll_* is the selected parent for
> several other clocks, which all end up with an unknown rate.
> So, I think it is worth investigating a little more how to properly
> read or otherwise specify the rate for clkph_mck_o.

Please see above.

> dpi_ck, infra_cpum, mm_dsi0_digital, mm_dsi1_digital, mm_lvds_cts -
> These are a dead-end (internal?) clock.
> It is probably fine if their rates are unknown (0 Hz).
> 
> usb_syspll_125m - This sounds like a fixed 125 MHz clock.  It is also
> a possible parent usb30 clock, so its value will propagate.
> 
> hdmitx_dig_cts - This is the root clock for the tree leading to
> mm_hdmi_pllck, which includes hdmitxpll_d* and hdmi_sel.
> However, I don't know how "mm_hdmi_pllck" is used.
> 
> mm_dpi1_pixel, mm_lvds_pixel - These two look very suspicious.  The
> similar "mm_dpi0_pixel" and "mm_hdmi_pixel" have parent dpi0_sel.
> It looks like maybe they should have "dpi1_sel" or "dpilvds_sel" as
> parents, but the _sel are not hooked up.

Subsystem clocks with parent clk_null may have different reasons. I'll
get back to you later.


Best regards,

James

  reply	other threads:[~2015-07-03  7:45 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18  5:29 [PATCH] arm64: dts: mt8173: add clock_null Eddie Huang
2015-06-18  5:29 ` Eddie Huang
2015-06-18  5:29 ` Eddie Huang
2015-06-18 16:15 ` Heiko Stuebner
2015-06-18 16:15   ` Heiko Stuebner
2015-06-18 16:15   ` Heiko Stuebner
2015-06-19 11:36   ` Heiko Stuebner
2015-06-19 11:36     ` Heiko Stuebner
2015-06-19 11:36     ` Heiko Stuebner
2015-06-22  3:38     ` James Liao
2015-06-22  3:38       ` James Liao
2015-06-22  3:38       ` James Liao
2015-06-22 12:53       ` Heiko Stübner
2015-06-22 12:53         ` Heiko Stübner
2015-06-22 12:53         ` Heiko Stübner
2015-06-24  7:54         ` James Liao
2015-06-24  7:54           ` James Liao
2015-06-24  7:54           ` James Liao
2015-06-24 10:24           ` Heiko Stübner
2015-06-24 10:24             ` Heiko Stübner
2015-06-24 10:24             ` Heiko Stübner
2015-06-30  9:07             ` James Liao
2015-06-30  9:07               ` James Liao
2015-06-30  9:07               ` James Liao
2015-07-01  6:49               ` Sascha Hauer
2015-07-01  6:49                 ` Sascha Hauer
2015-07-01  6:49                 ` Sascha Hauer
2015-07-01 11:54                 ` Daniel Kurtz
2015-07-01 11:54                   ` Daniel Kurtz
2015-07-02  3:06                   ` James Liao
2015-07-02  3:06                     ` James Liao
2015-07-02  3:06                     ` James Liao
2015-07-02  4:23                     ` Daniel Kurtz
2015-07-02  4:23                       ` Daniel Kurtz
2015-07-02  4:23                       ` Daniel Kurtz
2015-07-03  7:45                       ` James Liao [this message]
2015-07-03  7:45                         ` James Liao
2015-07-03  7:45                         ` James Liao
2015-07-03  8:38                         ` Heiko Stübner
2015-07-03  8:38                           ` Heiko Stübner
2015-07-03  8:38                           ` Heiko Stübner
2015-07-02  2:05                 ` James Liao
2015-07-02  2:05                   ` James Liao
2015-07-02  2:05                   ` James Liao
2015-07-07 13:07 ` Sascha Hauer
2015-07-07 13:07   ` Sascha Hauer
2015-07-07 13:07   ` Sascha Hauer
2015-07-07 14:15   ` Daniel Kurtz
2015-07-07 14:15     ` Daniel Kurtz
2015-07-07 14:15     ` Daniel Kurtz
2015-07-07 14:36     ` Sascha Hauer
2015-07-07 14:36       ` Sascha Hauer
2015-07-07 14:36       ` Sascha Hauer
2015-07-07 15:10       ` Daniel Kurtz
2015-07-07 15:10         ` Daniel Kurtz
2015-07-07 15:10         ` Daniel Kurtz
2015-07-08  2:37         ` Eddie Huang
2015-07-08  2:37           ` Eddie Huang
2015-07-08  2:37           ` Eddie Huang
2015-07-08  5:44           ` Sascha Hauer
2015-07-08  5:44             ` Sascha Hauer
2015-07-08  5:44             ` Sascha Hauer
2015-07-10  7:27             ` Eddie Huang
2015-07-10  7:27               ` Eddie Huang
2015-07-10  8:11               ` Daniel Kurtz
2015-07-10  8:11                 ` Daniel Kurtz
2015-07-10 10:29                 ` Eddie Huang
2015-07-10 10:29                   ` Eddie Huang
2015-07-10 10:29                   ` Eddie Huang

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=1435909512.3526.71.camel@mtksdaap41 \
    --to=jamesjj.liao@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djkurtz@chromium.org \
    --cc=eddie.huang@mediatek.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sboyd@codeaurora.org \
    --cc=ted.lin@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.