Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp140965imm; Thu, 30 Aug 2018 18:30:39 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdb7g/cgPO6q9I1YyaGAM2rX4yDazlN20iV6rlQmCDSQ3tZ54RN9CqdrNfquSFA9952iSz9i X-Received: by 2002:a62:6690:: with SMTP id s16-v6mr13271309pfj.152.1535679039871; Thu, 30 Aug 2018 18:30:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535679039; cv=none; d=google.com; s=arc-20160816; b=GNRaiJLIiROlocvdy0ZPt632aL8pA0AjCxDd16Rz2ohlhL3GAGozycuxKz5baalNgd 96HJeCohNjdmGmCwX0ebd16THoXgomYr0DHfv4CTb7fil2g3jF/duA9oXDkJNWTtzLny TKvU8py+nhNW2flLtBEpzx2B76U9ZdNjBEkO/CyTh1ni00yotgKBZOvCE3CwmSzEUUtS gZgOJtP64mOrVfVFlLXC5BCRW+OwgwR/wH4VPx8VnQ6oPmJZLFBBW+igZHiFHmILusLj wOx9BQS2M6s0kaKHpk9ATs4QDwMuHbtaEDpphN/NMd6XGlbX4SOLVs1zU3M8qaZtCOko jH7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature:arc-authentication-results; bh=BDsoP5G6dDU7wOY/YOWY7Pmjrr4PnV27ii0kVb0EKSw=; b=hxtilW2WLPoqkPCN9LI5u3CBzCd5I0YgIdrVMSI+kxoflY69wnKKn+0wzmVB75xXGQ wdqtBzmfIjDVkwO0kjMuVxOAekiCv/dV60vi26rvBbBZ8KgTOgy+YlxJ6nFmSDgDU/oW rb7HXDo9NNEyNewSlqum9xITFRTI4kmPD48JxdrFCS64KiSLyWBx8b19GJtvTZFzn7J1 ZxyATVMb4vKoj0W2EiCX/mo6g1CtsMAZjQE9LbUVaimne7k7XJC7qYdip/lrYMI+jEce sTrdooamLdUQUW1x7r9xjuTzHIohfxzbmX465sNVlyZunzWjKZoImMqPuI+ZXZTWRqm2 v6CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UhDSDQRt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1-v6si8538593plb.387.2018.08.30.18.30.25; Thu, 30 Aug 2018 18:30:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UhDSDQRt; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727281AbeHaFeG (ORCPT + 99 others); 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?