Messages in this thread | | | Subject | Re: [PATCH] arm64: dts: mt8173: add clock_null | From | James Liao <> | Date | Thu, 2 Jul 2015 11:06:19 +0800 |
| |
Hi Daniel,
On Wed, 2015-07-01 at 19:54 +0800, Daniel Kurtz wrote: > On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote: > > 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 */ > > }; > > It would be nice, though, to use the real clock rates. > Otherwise, we end up with a bunch of unknown clock rates, like this: > > clock enable_cnt prepare_cnt rate > accuracy phase > ---------------------------------------------------------------------------------------- > clk_null 2 2 0 > 0 0 > mm_lvds_cts 0 0 0 > 0 0 > mm_lvds_pixel 0 0 0 > 0 0 > mm_dpi1_pixel 0 0 0 > 0 0
> Furthermore, at least some of these children clocks are possible > source clocks for other clocks for which we do want to know the > resulting frequency. For example, the "dmpll_*" clocks are mux inputs > for many of the subsystem clocks.
These clocks such as clkph_mck_o are configured by other modules before kernel init, and their rates may different among platforms. So we can't use a hard-coded rate for them. And we also don't care the actual rate of these clocks, so assign a dummy rate such as 0 to them should be a better way.
Best regards,
james
| |