From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BE9CC433F4 for ; Fri, 31 Aug 2018 01:29:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C4B532083A for ; Fri, 31 Aug 2018 01:29:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="UhDSDQRt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4B532083A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727303AbeHaFeG (ORCPT ); Fri, 31 Aug 2018 01:34:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:45110 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725772AbeHaFeG (ORCPT ); Fri, 31 Aug 2018 01:34:06 -0400 Received: from localhost (unknown [104.132.0.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C6D2C20837; Fri, 31 Aug 2018 01:29:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1535678947; bh=BDsoP5G6dDU7wOY/YOWY7Pmjrr4PnV27ii0kVb0EKSw=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=UhDSDQRtkGXS6P36o1hDZchM//jDZljoAgSe6t+ndVR0mZZ5yCw9XHL/nVQyuuM16 N+hkWkxKjvho6PPTtsEMRxGcVh6dZDRRKqi3kdv5YYAVDiBMofdXUzs/pWWivg83uJ Umhh+nsVWUUtNYe9KAoMz1VDNcwqr52CkxmLGNDw= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: "kernel@pengutronix.de" , "linux-arm-kernel@lists.infradead.org" , "linux-clk@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mturquette@baylibre.com" , "s.hauer@pengutronix.de" , "shawnguo@kernel.org" , Anson Huang , Fabio Estevam , Peng Fan , Rob Herring From: Stephen Boyd In-Reply-To: Cc: dl-linux-imx References: <1533703167-26583-1-git-send-email-Anson.Huang@nxp.com> <1533703167-26583-2-git-send-email-Anson.Huang@nxp.com> Message-ID: <153567894721.93865.4092113232222931488@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array Date: Thu, 30 Aug 2018 18:29:07 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Peng Fan (2018-08-12 18:15:41) > Hi Anson, > = > > > > -----Original Message----- > > > > From: Anson Huang > > > > Sent: 2018=E5=B9=B48=E6=9C=888=E6=97=A5 12:39 > > > > To: shawnguo@kernel.org; s.hauer@pengutronix.de; > > > > kernel@pengutronix.de; Fabio Estevam ; > > > > mturquette@baylibre.com; sboyd@kernel.org; > > > > linux-arm-kernel@lists.infradead.org; > > > > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Cc: dl-linux-imx > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array > > > > > > > > Clock framework will enable those clocks registered with > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during > > > > clock > > > initialization now. > > > > > > Will it be more flexible to parse dts saying "critical-clocks =3D " > > > or "init-on-arrary=3D" > > > and enable those clocks? > > = > > Parsing the clocks arrays from dtb is another way of enabling critical = clocks, but > > for current i.MX6/7 platforms, we implement it in same way as most of o= ther > > SoCs, currently I did NOT see any necessity of putting them in dtb, jus= t adding > > flag during clock registering is more simple, if there is any special r= equirement > > for different clocks set to be enabled, then we can add support to enab= le the > > method of parsing critical-clocks from dtb. Just my two cents. > = > Thinking about OP-TEE want to use one device, but it's clocks are registe= red > by Linux, because there is no module in Linux side use it, it will shutdo= wn the clock, > which cause OP-TEE could not access the device. > = > Then people have to modify clk code to add CLK_IS_CRITICAL flag to make s= ure > the clocks are not shutdown by Linux. > = > However adding a new property in clk node and let driver code parse the d= ts, > there is no need to modify clk driver code when OP-TEE needs another devi= ce clock. > = If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled forever?