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@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html