Re: [PATCH] arm64: dts: mt8173: add clock_null

[James Liao]

Hi Sascha,

On Wed, 2015-07-01 at 08:49 +0200, Sascha Hauer wrote:
> On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote:
> > There are 4 clocks which are derived from clk_null directly in current
> > topckgen implementation:
> > 
> > 	clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts
> > 
> > Our designer mentioned 2 things about external clocks:
> > 
> > 1. These 4 clocks come from analog macro, not from PLL, nor from
> > external clocks directly.
> 
> Ok, this means there actually are clocks. We can't control these clock and
> they have some known or unknown rate. This makes them fixed clocks. Just
> specify them in the device tree and you are done. Give them reasonable
> names and the rate if you know it, 0 otherwise.
> 
> The problem is not that you use fixed clocks for non software
> controllable clocks of unknwown rates, but that you try to use a single
> clock for all of them and name it 'dummy' or 'null'. Name it
> 
> dpi_ck {
> 	compatible = "fixed-clock";
> 	rate = <0>; /* unknown, generated by some Analog block */
> };
> 
> Technically it's the same, but it sounds much more professional and like
> you know what you are doing ;)

These clocks are SoC internal clocks. Is it suitable to specify them in
the device tree?

According to your and Heiko's suggestion, it looks the best way should
be specifying these clocks in the driver code without a dummy parent.
i.e.:

Original code:

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),

New code:

FIXED(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", UNKNOWN_RATE),
FIXED(CLK_TOP_DPI, "dpi_ck", UNKNOWN_RATE),
FIXED(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", UNKNOWN_RATE),
FIXED(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", UNKNOWN_RATE),

Then we don't need to specify a dummy clock such as clk_null in device
tree.


Best regards,

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/