Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7582664rdb; Thu, 4 Jan 2024 00:35:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IFjmHyvIBu1uU/SlWjb9wzqnlqUPS90Hwyr91Wrr7DYBgzeXtfYo6Sn21yCa2AwKDwEoiHq X-Received: by 2002:a05:6214:d8e:b0:67f:9d81:829c with SMTP id e14-20020a0562140d8e00b0067f9d81829cmr356186qve.119.1704357347412; Thu, 04 Jan 2024 00:35:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704357347; cv=none; d=google.com; s=arc-20160816; b=uWOqtqYvQ86W4AfGWEA7n0bNUKmrnl2INJl0IfMJY5tcIu4XilPCZeSrB1nKAHiTL7 QOrHVfaoVDSiz9HrLraUKYVjm+6SOm5xeOg2lNLWqdNFyC5RCv6LqO28M5ZIVimf3Bgy K5MjNMIsM0nWG2Q7oU5wVFj3qWuRLXFkpCo6lCgs1Q7qReV0fSRInVGrXfjxjkVH5pQl ck3QVCiodKT/M7qS/ErLvcjLceJkHSwefEUDPsk1H/EtdXZwbsEtg0vVTktddDEvl+Vw v+PjlQ7Z8mujD7SDsWpnRjCHNreAqUwN3KGLdaRsTwpg/1CHeySLR7LyrFWx05xUz1JQ 5lQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Czxn87VisuGDVKFjWsbYEOh5J4GyHjQzygqDUWfW5Mo=; fh=T5Qy85KLaypVtzPWbsVBEvNEqQOyAn9gVQI2wr3wknA=; b=jUSOuJKkVSrohutWzdjBdmtG2fzenLhl7FJEgfqGFZO8hgdDwWO0r/YjTG8EZJ1ikV K/UPpbLaeJqosvfVk0zQ2ZiVPWj4+B2HX0Y68TAK/Z6LKt4VT77PJYXBuCt3YYCbWUUZ 7htmKpK0jH597Rbvn2qyfl6TuHUQ5QUwDBn1ihOox4suwy7gywcL5Sj6c98d4FUrUoRf ACRdAbY6fx3q2d2/+D6iW8z+LDpYmju14q8CJmFC3pw1gxAo7F5l5a/W6w27/kN2NpHO PAz0jPo7hsgplt0RhFmme+Wvm20dy9jgHHLcuYUaa/eJhz01ZaKXypYXAero62j2DZm4 kduQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=c7a0LErj; spf=pass (google.com: domain of linux-kernel+bounces-16370-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16370-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id i23-20020a0cab57000000b0067f14fbeb3dsi31211510qvb.51.2024.01.04.00.35.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 00:35:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16370-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=c7a0LErj; spf=pass (google.com: domain of linux-kernel+bounces-16370-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16370-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 2F43F1C21405 for ; Thu, 4 Jan 2024 08:35:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0398E1DDD4; Thu, 4 Jan 2024 08:35:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c7a0LErj" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 292E91DDC5; Thu, 4 Jan 2024 08:35:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CB37C433C7; Thu, 4 Jan 2024 08:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704357336; bh=VVKDivnQXUpx/mJCI1TLLwv2PY3eYbl6Za9p/h/xf3Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=c7a0LErjThbcPLeFdt4cA5awUebgBKpwxGWHJZBo+RX4jPMFw8oXnQHHEvJczlC1O KcZ6D9Xfh7mAFQ9ZMiuCeK+gYHdupeAi4gvo3VcagbJLsZvcaJZSVefacQ6QULCI5U 6V3SX01mP45VbUBYSNq/YvUlicMi8pJqs8Uwm61O9b3cFKD/BYoCow8XMzrscT1s/4 F7axRm9DP8WNNGLetSkagZVjDx4nJ4XKLi31w5hi9paKTD0qEtbbgdKdoO9pB6ZbSw t9Ta8BHy7sVB+LFUwjXyHpvsznaQmRXEUNsypLAjowf2cvEe+P3faUGjXxx3l2UjOg cE2GBq4uGFVRw== Received: from johan by xi.lan with local (Exim 4.96.2) (envelope-from ) id 1rLJCP-0007e1-1S; Thu, 04 Jan 2024 09:35:33 +0100 Date: Thu, 4 Jan 2024 09:35:33 +0100 From: Johan Hovold To: Konrad Dybcio Cc: Bjorn Andersson , Andy Gross , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Marijn Suijten , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v5 03/12] clk: qcom: gcc-sm6375: Unregister critical clocks Message-ID: References: <20230717-topic-branch_aon_cleanup-v5-0-99942e6bf1ba@linaro.org> <20230717-topic-branch_aon_cleanup-v5-3-99942e6bf1ba@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230717-topic-branch_aon_cleanup-v5-3-99942e6bf1ba@linaro.org> On Wed, Jan 03, 2024 at 02:36:01PM +0100, Konrad Dybcio wrote: > Some clocks need to be always-on, but we don't really do anything > with them, other than calling enable() once and telling Linux they're > enabled. > > Unregister them to save a couple of bytes and, perhaps more > importantly, allow for runtime suspend of the clock controller device, > as CLK_IS_CRITICAL prevents the latter. > > Signed-off-by: Konrad Dybcio > @@ -3886,6 +3797,11 @@ static int gcc_sm6375_probe(struct platform_device *pdev) > qcom_branch_set_clk_en(regmap, 0x17028); /* GCC_CAMERA_XO_CLK */ > qcom_branch_set_clk_en(regmap, 0x2b004); /* GCC_CPUSS_GNOC_CLK */ > qcom_branch_set_clk_en(regmap, 0x1702c); /* GCC_DISP_XO_CLK */ > + qcom_branch_set_clk_en(regmap, 0x17008); /* GCC_CAMERA_AHB_CLK */ > + qcom_branch_set_clk_en(regmap, 0x1700c); /* GCC_DISP_AHB_CLK */ > + qcom_branch_set_clk_en(regmap, 0x36004); /* GCC_GPU_CFG_AHB_CLK */ > + qcom_branch_set_clk_en(regmap, 0x79004); /* GCC_SYS_NOC_CPUSS_AHB_CLK */ > + qcom_branch_set_clk_en(regmap, 0x17004); /* GCC_VIDEO_AHB_CLK */ Shouldn't you keep the above sorted by offset or at least try to group them by subsystem (e.g. keep the camera clocks together)? Johan