Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3189880ybc; Mon, 25 Nov 2019 10:21:04 -0800 (PST) X-Google-Smtp-Source: APXvYqzhUcPMIFBvzmPMX9TxsI5uG6irqfkIEMw7qAcG2cv7digoNd/S3rrU7XhHBLnK1vlYOdgd X-Received: by 2002:a17:906:b253:: with SMTP id ce19mr12511127ejb.61.1574706064521; Mon, 25 Nov 2019 10:21:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574706064; cv=none; d=google.com; s=arc-20160816; b=SFFUiqfxYg5aSPUf7wh0rSr9N7ead6SsoliXRvsFTyk2JSvW5IewKsAmfdlwmL7gb4 PH747Zc6bZzeZ/uBuCga54HjQYUELWVRdQbXqh3litIi4ZIlcgOH+wj7bkb9k6FpaKlI xT5CvBii1aiK7ynCUN15mrsyP8pfNei7kvVurm8gAupguecOt28aUZimVICijbz4MRhg 1M7HvQQQX8gZrMg4e8IMsSzhkpTaZy+hkK49NbcFzbddCSCnCPA37lCiCtLCmq3Otog0 XQ5h7EwaaMALrjaRITN6DVooa651uLKy9QIb9M0jHY4vuMbqq6fgh5LuMwFpmEB5Zj8A xNuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=iVO+CFyKdAbmAXju99HzrtWINdnWqXd4ouQqZQnSQvc=; b=F+INEEo4pwoueZRfILQ8P8vfEpb1AYebtntzDMCoMwfLRtM4XQ7xWz9GDrWUEfAvZ/ chZopTEB+Zhvsd62SftbvZsNn/2sywGaG7aefMniOwRjoBKrZXwP/YWwFIGl/YfUV+Tz WzmhW6LaWbVh5aycBmvgPnaPAry/ZO3K8ZOb6qcEDSJkH5tcs5tn9myOGqhOrvgoh5Ly nYhraY1ZCDYLg9TF3xYhcRxwQRIZH6MagpFonEmbcElQAnkH23CXFlD7fjGhKaOPPBro D5N0F+HfkT+tl8ebByFtskQJSsh8Xw1FAuB7uqlfsRys0Twav2hjTX2YQhSE7u5n5Vlq CF6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b="fiQ9YBB/"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c25si5069091ejm.224.2019.11.25.10.20.40; Mon, 25 Nov 2019 10:21:04 -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=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b="fiQ9YBB/"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727704AbfKYNh7 (ORCPT + 99 others); Mon, 25 Nov 2019 08:37:59 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:35322 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbfKYNh6 (ORCPT ); Mon, 25 Nov 2019 08:37:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: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=iVO+CFyKdAbmAXju99HzrtWINdnWqXd4ouQqZQnSQvc=; b=fiQ9YBB/hSo8uJJBQ0xbyC0SJ 4SjorX4fJ+YbzhLDrCpbu8fQMbxPc7P8HJ855cFcnJeJG4mRyHha8NFB2UO6WROLIvmdBIkKAcVm0 ml0JebgN+rS+UqdjhIJGYIFh+1uAJnIO1HBusMt0+B8TJuvE0ZkhHcSxYzkkWp344lAsF/1gnHTGD Al26t+QS3P2wMVJZ7kJqIhnVtOdX9W0glwxpkIOXI32qaBZLFgMFZAJz1CxS4uSm91EiGz4+pgYFx 69buvLxxLLtdrTeAVYEP06S3dBOO04wzNcO+aQMoboi7JpCn+DaXPWC5PQKzurNT1UM7aohsSrbZi Pf6nPTUvQ==; Received: from shell.armlinux.org.uk ([2001:4d48:ad52:3201:5054:ff:fe00:4ec]:32786) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iZEYr-0007zV-2p; Mon, 25 Nov 2019 13:37:53 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1iZEYq-0006i3-72; Mon, 25 Nov 2019 13:37:52 +0000 Date: Mon, 25 Nov 2019 13:37:52 +0000 From: Russell King - ARM Linux admin To: Marc Gonzalez Cc: Stephen Boyd , Michael Turquette , linux-clk , Linux ARM , LKML Subject: Re: [PATCH v1] clk: Add devm_clk_{prepare,enable,prepare_enable} Message-ID: <20191125133752.GS25745@shell.armlinux.org.uk> References: <1d7a1b3b-e9bf-1d80-609d-a9c0c932b15a@free.fr> <34e32662-c909-9eb3-e561-3274ad0bf3cc@free.fr> <20191125125530.GP25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 25, 2019 at 02:10:21PM +0100, Marc Gonzalez wrote: > On 25/11/2019 13:55, Russell King - ARM Linux admin wrote: > > > It's also worth reading https://lore.kernel.org/patchwork/patch/755667/ > > and considering whether you really are using the clk_prepare() and > > clk_enable() APIs correctly. Wanting these devm functions suggests > > you aren't... > > In that older thread, you wrote: > > > If you take the view that trying to keep clocks disabled is a good way > > to save power, then you'd have the clk_prepare() or maybe > > clk_prepare_enable() in your run-time PM resume handler, or maybe even > > deeper in the driver... the original design goal of the clk API was to > > allow power saving and clock control. > > > > With that in mind, getting and enabling the clock together in the > > probe function didn't make sense. > > > > I feel that aspect has been somewhat lost, and people now regard much > > of the clk API as a bit of a probe-time nuisance. > > In the few drivers I've written, I call clk_prepare_enable() at probe. Right, so the clocks are enabled as soon as the device is probed, in other words at boot time. It remains enabled for as long as the device is bound to its driver, whether or not the device is actually being used. Every switching edge causes heat to be generated. Every switching edge causes energy to be wasted. That's fine if you have an infinite energy supply. That hasn't been discovered yet. Given the prevalence of technology, don't you think we should be doing as much as we possibly can to reduce the energy consumption of the devices we use? It may be peanuts per device, but at scale it all adds up. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up