Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1376932imm; Thu, 4 Oct 2018 12:35:25 -0700 (PDT) X-Google-Smtp-Source: ACcGV6173FBQUJKeQDlvJ/ktaVlvKQYWWk0xkZu4TVlAmbXA5ebqjreDlPJMEKWuDKL0rWY/NHOq X-Received: by 2002:a63:f05:: with SMTP id e5-v6mr6785606pgl.84.1538681725803; Thu, 04 Oct 2018 12:35:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538681725; cv=none; d=google.com; s=arc-20160816; b=qDm1ndkurkt+En/k6CTl3Nha/CLlSrEB0LnS/JDR5SbgMDJlkizwo4kcuC6b7LSuUn TXezyWYX54ASTF5KA4DzWt5sZaQxd7LmvO4D0SSYdRqtOjKCUsGpFlqGO7Vz6mNGUTjR 87/5JsZIkSygYnkOALTTUfvYRVfQ6lxNy/wVhnwDAo8CF0sMKzy3xap3BSh7h4rE638w omHpkgtDUHWbD3jsx/mfWxFj8UlvfVJVDZcPznugLvR6aJi3tKh0ku33duXvCsbV8jI8 tHBFi1bw5DydeUnzbx3T6EOuIaBMB1YynwkZ8WNU8a5WxD7apqvvNENwikokYxDzNuVj zSdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:dkim-signature; bh=BuQLrtChRyBTYyuIDcmVQimPper4LvVNyYDui4Vrnbw=; b=crtH5hzHMUhnUeaKAT4Uaz+aHusi1MkfdsMLN6ELzILFU65d78XpEGKg1qgyTch4lc khLdkZf0zBil/5va92CglGz8e3qgyNg3nMlLwd9auajsoMcOgvjDJ6Aw798UMSni+SKI QGNCEi/dr6rmc2JZrVD5QR4RdEqleb5MiE7iovNg9f0DWCroyy10/fLZtMhv+yORtjPg iV/BkiTfjdUxQqnb1SssFzv4RJPdRYWB7ZDWFJTQhlMrhr58OAp60b6qUR9dQsXn2KRN 8Qd8pBFwjUKX8hzzusHInQrEcayYszbQ3UQLKoztqzpMhvgQSBqS+3cpOCj4bq/RlZqW y30Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@kemnade.info header.s=20180802 header.b=eVzfrA9h; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c197-v6si6250573pfc.74.2018.10.04.12.35.10; Thu, 04 Oct 2018 12:35:25 -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=fail header.i=@kemnade.info header.s=20180802 header.b=eVzfrA9h; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727645AbeJEC3p (ORCPT + 99 others); Thu, 4 Oct 2018 22:29:45 -0400 Received: from mail.andi.de1.cc ([85.214.239.24]:33778 "EHLO h2641619.stratoserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727506AbeJEC3p (ORCPT ); Thu, 4 Oct 2018 22:29:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20180802; h=Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BuQLrtChRyBTYyuIDcmVQimPper4LvVNyYDui4Vrnbw=; b=eVzfrA9hJG2ZzbhxL38+6OJZz eNqBoA75HNA/gdm+7kwByDRlj1dTjVb3gGI2XwK8Y37qThGR1b9E+yt+kKULqjXd+mwvg52odJUny AhZL+puW3nzzWqcg9gssxoPEJnWdPeUWi02T8QDeCEkL9Qg/EypdNd4aKyBUbdRrmHmHY=; Received: from pd9e2f808.dip0.t-ipconnect.de ([217.226.248.8] helo=aktux) by h2641619.stratoserver.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1g89Og-0006NZ-9k; Thu, 04 Oct 2018 21:34:54 +0200 Date: Thu, 4 Oct 2018 21:34:48 +0200 From: Andreas Kemnade To: Tero Kristo Cc: , , , , , , , Subject: Re: [PATCH RFC 1/2] clk: ti: add a usecount for autoidle Message-ID: <20181004213448.55c08208@aktux> In-Reply-To: References: <20181004055147.23048-1-andreas@kemnade.info> <20181004055147.23048-2-andreas@kemnade.info> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/DI2+y_6kLlI.i7YQdkdRjJF"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/DI2+y_6kLlI.i7YQdkdRjJF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, On Thu, 4 Oct 2018 17:40:06 +0300 Tero Kristo wrote: > On 04/10/18 08:51, Andreas Kemnade wrote: > > We have the scenario that first autoidle is disabled for all clocks, > > then it is disabled for selected ones and then enabled for all. So > > we should have some counting here, also according to the > > comment in _setup_iclk_autoidle() > >=20 > > Signed-off-by: Andreas Kemnade > > --- > > drivers/clk/ti/autoidle.c | 20 ++++++++++++-------- > > include/linux/clk/ti.h | 1 + > > 2 files changed, 13 insertions(+), 8 deletions(-) > >=20 > > diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c > > index 7bb9afbe4058..be2ce42e4f33 100644 > > --- a/drivers/clk/ti/autoidle.c > > +++ b/drivers/clk/ti/autoidle.c > > @@ -48,8 +48,11 @@ int omap2_clk_deny_idle(struct clk *clk) > > struct clk_hw_omap *c; > > =20 > > c =3D to_clk_hw_omap(__clk_get_hw(clk)); > > - if (c->ops && c->ops->deny_idle) > > - c->ops->deny_idle(c); > > + if (c->ops && c->ops->deny_idle) { > > + c->autoidle_count--; > > + if (c->autoidle_count =3D=3D -1) > > + c->ops->deny_idle(c); =20 >=20 > This code is racy as you have no locking in place. Please fix. >=20 hmm, yes, it is. Due to low risk (things are only called from init before the drivers are initialized, if I understand that correctly). I kept that for final polishing and not for a rfc patch. The deny_idle/allow_idle are also racy themselves. Multiple clocks with bits in the same register changed at the same time would also create a mess. > Also, this should be verified that it doesn't cause any PM regressions,=20 > I hope you have done that? >=20 Tested things: I checked various autoidle registers for changes. I checked registers by reading out /dev/mem Seen changes: hdq iclk no autoidle (that is the goal of all this) dss iclk no autoidle. This one is really interesting: There are multiple users of dss_ick, so that is a special case. I will check whether I can handle that (I have already an idea) or just delete that flag there for sorting out that later, we could somehow live with not disabled autoidle flag there but needed some strange fixes in the past. Now dss_ick does unecessarily enabled, so yes, a little regression. CORE/PER idlest seems to behave as well as before that change. Regards, Andreas --Sig_/DI2+y_6kLlI.i7YQdkdRjJF Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE7sDbhY5mwNpwYgrAfb1qx03ikyQFAlu2a1gACgkQfb1qx03i kyTUJw//bk67LvreD5J0A92GGWjzLptxyyqnzPs6JmSzGymmvcNzCfwUFHri76CT xDBs5DyRUWcTg51aRFmjcYS1yBx3UJSscDX52V2CPYF6zvhfWL3w92VDlqawdQjt ADIRnpiFA/JsaRakszMia/2Yvqybf/eXchmE/PVZgn8IQnFJW0SgcvBXrUmFVznX 55nkSeBThO8Rt/1JWmeaUp73m4MPZ0IDp0/5a2nFRMoIp1Arkd632MbWKesT7sD+ d84LSP5MEslEpB0mHdXNgkuJfxS0WcgrkXeVuvTJq3JkJSy+LQLYlyDwAJkfC8TV /FO8lYFFnH7GcgdNhPmv3r/iUrdSUIujIat5oyUpuz00AVMA0+tstrQxQ2mIRIpM P/2+h8AL+4el+bNQRYCPMCckCVj/zvzSD2XVnAc9N5q+GD4UYQQ3+9CZanpETr16 XFMAK5nzGpxPI0f13utAsunRMk+7RNX3ECybnO/402T/CQYepITQWhjig5n5nDx8 ZHvBHKLmWBxVPvg0ml598m5PHRO/FCbCBPK1hfSd1fhy9HN9Ya/LW6EjAyjY9s9c v8jOw3eik4iokdz5zSxhhdArqU0mO4FwA8p5/lTLC/Fuurr9gnpxIm1Xr5nMIWik 0O0/1OqtM2LwgQ1IvfAenwODCaKcwSG1VupZzG8rj0+mt2DbNuE= =xAN8 -----END PGP SIGNATURE----- --Sig_/DI2+y_6kLlI.i7YQdkdRjJF--