Thread (24 messages) flat view 24 messages, 5 authors, 2015-07-10

[PATCH] arm64: dts: mt8173: add clock_null

From: James Liao <hidden>
Date: 2015-07-02 03:07:16
Also in: linux-devicetree, linux-mediatek, lkml

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 [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help