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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Jul 2015 11:06:19 +0800
From:	James Liao <jamesjj.liao@...iatek.com>
To:	Daniel Kurtz <djkurtz@...omium.org>
CC:	Sascha Hauer <s.hauer@...gutronix.de>,
	Heiko Stübner <heiko@...ech.de>,
	"open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>,
	Mike Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	<linux-mediatek@...ts.infradead.org>, <ted.lin@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	"Eddie Huang" <eddie.huang@...iatek.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: dts: mt8173: add clock_null

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@...gutronix.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


--
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/