linux-kernel - Re: [PATCH] arm64: dts: mt8173: add clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGS+omBdz2df7ykYpx5Gh1B2Ym+XhpOPOOUu0a_qg7tJKqOy6A@mail.gmail.com>
Date:	Wed, 1 Jul 2015 19:54:09 +0800
From:	Daniel Kurtz <djkurtz@...omium.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	James Liao <jamesjj.liao@...iatek.com>,
	Heiko Stübner <heiko@...ech.de>,
	linux-mediatek@...ts.infradead.org,
	Eddie Huang <eddie.huang@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	"open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>, ted.lin@...iatek.com
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null

On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer <s.hauer@...gutronix.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/