Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3447864imu; Thu, 29 Nov 2018 23:58:14 -0800 (PST) X-Google-Smtp-Source: AFSGD/VDJpcGk9kgdn+xqBhDd9VPN3MsN3bKz7+UVfGGEjbsrW3vARynq3uWHifbEJ4Axv1/TuDz X-Received: by 2002:a63:5518:: with SMTP id j24mr3942361pgb.208.1543564694015; Thu, 29 Nov 2018 23:58:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543564693; cv=none; d=google.com; s=arc-20160816; b=RQXyMWJc3xKxD4o4Xji7PUGK/o/crTC2hWTjl3vZOf6Wm+6/rAsvYNbs2q+5bSUf+K L3IXSodNhDXzovDfrz5tPwfwyFL/2UrU6OFB+NePuhAN9mTIzfLAdPYIhQaNFZ4HxTYQ IYx7ahZsnRmPOmWkmV8shy/LV2C+bMpsRH0QxDBcffqnBChLfAfIp4Ak5OjVFMxXUv95 5e2gR7R07miYIdgOzqHyGDL2np84Rs8d5rXJQQzBgBZsCjUHmv44j8GEUQI/LtYmnuyd WhSGRBLaEmM+uYa0GxgR60pSNTp9JAdY9HQvMvPWkuG0Aw6EMAXwMDSraUz7VZphK7dV 7e2A== 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; bh=9IQEsjWUp03OFzWtieU5Zy/Ayqs3fMZ3YxwhxT11rUQ=; b=vsZwpPQQGmUJ2MNL+VZdnHrFmQLkX7c+1MSG9nxN0Y3HVXkI3Vgd7S0dxy7eLViFoE cCKJkcSMciIeTy9+CgC0Vm3/RlWl0Eq6pJG9SHFMkQtLy8gqmYZPnc4mf1grEfmP9Qqf gwHFagu3sHRBtoAS4fN2xVRIqpCuftlGXPUAPT4dEK9B1DWyMUnjIPJ6drz+GOP+g9up hy71K7tCk4faDptMpfrKkwEb090AZwUXNKMe59aZbAwsKjurwp+TrTyx+4r13FmH4Gs8 u99KA0MVUdfWjml4nlnnUL9LBRHlSXiZrOifkkhGg4qOKezVD2G4nvhTi3RG+nqd9LN6 sd9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=HydGg5va; 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 d2si4999989pfe.159.2018.11.29.23.57.59; Thu, 29 Nov 2018 23:58:13 -0800 (PST) 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=HydGg5va; 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 S1726974AbeK3TFk (ORCPT + 99 others); Fri, 30 Nov 2018 14:05:40 -0500 Received: from mail.kernel.org ([198.145.29.99]:35860 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726551AbeK3TFk (ORCPT ); Fri, 30 Nov 2018 14:05:40 -0500 Received: from localhost (unknown [104.132.0.74]) (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 918C72082F; Fri, 30 Nov 2018 07:57:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543564633; bh=45XbyJDAV+rjS6BURMjquRfCzLZ7P2sZjr9xmYBgirw=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=HydGg5valyBGLSi2BK5BMf6tt6P6RM7pAp+QXfLeqsezvo3DpddeF/zbrzovCHof6 bYasXbs6SspbsxfwfE9lEoWlqK1nriWKzrbfpOiCPHbav3I7agiIUIccUovg7XPJJH kcK1ylDd47XlAzNVVySGLi+8G2OGI0VMLtjCRlOI= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Andreas Kemnade , Tero Kristo From: Stephen Boyd In-Reply-To: <9eb7b090-4803-d389-4112-3bf058385b2e@ti.com> Cc: bcousson@baylibre.com, letux-kernel@openphoenux.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, mturquette@baylibre.com, paul@pwsan.com, tony@atomide.com References: <20181110203115.13335-1-andreas@kemnade.info> <20181110203115.13335-3-andreas@kemnade.info> <154353750560.88331.11814738542436183126@swboyd.mtv.corp.google.com> <20181130071534.0a6cd455@kemnade.info> <154356242517.88331.8496814814468751012@swboyd.mtv.corp.google.com> <9eb7b090-4803-d389-4112-3bf058385b2e@ti.com> Message-ID: <154356463284.88331.13323307899580657085@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops Date: Thu, 29 Nov 2018 23:57:12 -0800 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Tero Kristo (2018-11-29 23:35:35) > On 30/11/2018 09:20, Stephen Boyd wrote: > > Quoting Andreas Kemnade (2018-11-29 22:15:34) > >> Hi Stephen, > >> > >> On Thu, 29 Nov 2018 16:25:05 -0800 > >> Stephen Boyd wrote: > >> > >>> Quoting Andreas Kemnade (2018-11-10 12:31:14) > >>>> Code might use autoidle api with clocks not being omap2 clocks, > >>>> so check if clock type is not basic > >>>> > >>>> Signed-off-by: Andreas Kemnade > >>>> --- > >>>> New in v2 > >>>> --- > >>>> drivers/clk/ti/autoidle.c | 12 ++++++++++-- > >>>> 1 file changed, 10 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c > >>>> index 161f67850393..5bdae5552d38 100644 > >>>> --- a/drivers/clk/ti/autoidle.c > >>>> +++ b/drivers/clk/ti/autoidle.c > >>>> @@ -54,8 +54,12 @@ static DEFINE_SPINLOCK(autoidle_spinlock); > >>>> int omap2_clk_deny_idle(struct clk *clk) > >>>> { > >>>> struct clk_hw_omap *c; > >>>> + struct clk_hw *hw =3D __clk_get_hw(clk); > >>>> = > >>>> - c =3D to_clk_hw_omap(__clk_get_hw(clk)); > >>>> + if (clk_hw_get_flags(hw) & CLK_IS_BASIC) > >>> > >>> Please try to avoid using CLK_IS_BASIC if at all possible. Can you? > >>> Maybe add some flag in clk_hw_omap() instead? > >>> > >> hmm, Tero suggested that. > >> But to check flags in clk_hw_omap I first need to know that there is a > >> clk_hw_omap behind clk_hw. And for that I either need to check flags in > >> clk_hw or do more changes in the omap_hwmod code. > > = > > Can you do it? The omap code is the only user of CLK_IS_BASIC. All the > > other users are marking clks with this but there is no reason to do so. > > I'll go make another pass over the tree and nuke those ones from orbit. > = > The reason for using this flag is because OMAP uses two clock types = > around, the basic clocks like fixed-factor-clock/fixed-clock, and then = > all the omap derivatives, which can be cast to clk_hw_omap. If we want = > to avoid usage of CLK_IS_BASIC, we need to copy paste the remaining = > basic code under drivers/clk/ti/ and convert them to use clk_hw_omap as = > internal datatype. Is this preferred? > = No that is not preferred. Can the omap2_clk_deny_idle() function be integrated closer into the clk framework in some way that allows it to be part of the clk_ops structure? And then have that take a clk_hw structure instead of a struct clk? I haven't looked at this in any detail whatsoever so I may be way off right now.