[PATCH] arm64: dts: mt8173: add clock_null

[Daniel Kurtz]

On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
>
> On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote:
> > Hi Heiko,
> >
> > 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 */
> };

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
    mm_dsi1_digital                       0            0           0
       0 0
    mm_dsi0_digital                       1            1           0
       0 0
    infra_cpum                            0            0           0
       0 0
    hdmitx_dig_cts                        0            0           0
       0 0
       hdmi_sel                           0            0           0
       0 0
          mm_hdmi_pllck                   0            0           0
       0 0
       hdmitxpll_d3                       0            0           0
       0 0
       hdmitxpll_d2                       0            0           0
       0 0
    usb_syspll_125m                       0            0           0
       0 0
    dpi_ck                                0            0           0
       0 0
    clkph_mck_o                           1            1           0
       0 0
       dmpll_d16                          0            0           0
       0 0
       dmpll_d8                           0            0           0
       0 0
       dmpll_d4                           0            0           0
       0 0
       dmpll_d2                           0            0           0
       0 0
       dmpll_ck                           1            1           0
       0 0
          mem_sel                         2            2           0
       0 0
             infra_m4u                    1            1           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.

-Dan

>
> Technically it's the same, but it sounds much more professional and like
> you know what you are doing ;)
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/