From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AFAC0C4332F for ; Tue, 17 May 2022 18:43:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LpYmW/UhSwDihvBtVTI0sATb3pPzo8QE5J1s/vKr8bo=; b=UvsJNgRYuLQe9j 0rX78OJfkon7IlXPURPrDPWze02GOofxaVdLf/8wC8+cNes0UOZY6bqUyLOGLOIenpa01j2xzuWPV 8I88ECZmtw5VwU8pWyIkWPOngPBqztDU+Jw8UdMNKlwKNRONVJE3xuLOUPss6/B8njgRXy7C36maq DPeVhIirr66YxURe/VkRKt7cj78bU4DOAgx0KwuR6k6ZAnM0rb+ENXKGttXi5r1aDW9kvJ9qb/abu h8QuwKgFat9K3YBru+BwF13ToZ0C8XXmlxv82XvMNxWwsOH2I245oY+eawkPthdWR6BaMMD2XjEma e+ZW8jzRoD6QoDO7HZsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr29h-00FNPe-AH; Tue, 17 May 2022 18:42:49 +0000 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr29d-00FNNh-Az for linux-arm-kernel@lists.infradead.org; Tue, 17 May 2022 18:42:47 +0000 Received: by mail-io1-xd2d.google.com with SMTP id q203so4434734iod.0 for ; Tue, 17 May 2022 11:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kh4EnLD5q25bV5mnKOfEKUkGgPpU5YAK0WJ01JIxNg4=; b=aUrMJiwv/pKGCIiR1FDh6ybW4X9ORE3GqTTU46RKMu/5qjgrJedBoy12P6roStHy+d UDkoTN0toafzpAhVeCVBaef5V88Nc5mlJNtf+347enG/JDAAcYlQUmX0buXocznHk5Ko jasUD1NLA/aFd66v+Hllo1XnExWtr7zC6s7H5i3HGDx8o8qwDH9VEMs1jfdpj4jw/5tf c/N1bFsySnbbP76od6uYB40iaMD9qPoNRKPUcfxEN6TAIBj1nX09xS58DzZvQeKS+i55 rZ0ezrhe+BDDtQVGCvwcKG3PqWIDufzzV0gy5XihuCNMzywqD9n1CQYC5Mnv1Uq1CqHC 0MFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kh4EnLD5q25bV5mnKOfEKUkGgPpU5YAK0WJ01JIxNg4=; b=blNVMuxl4PK4gPcL4erWeh16Swxa9itz0qMHerCoarXsAokm3eAD5l/FOorC/PdavZ 11p9g2n4O4G3m+R7y/vRXDLWRh16WdBpSafHriWuOXAkz5TkPEuWb8ahkAVYTHJHyiMu EJG9RDDg7WAqei9HqnbONCU9hihkqCIAgU3NZbMZlQCAmXhT7ciQ26VwTBHoxEmUl+Kg Tft8d9eBvuOZerVQVZIiTYVqxmuggCMiaFSJCs0NGK7urerO1pE8DX6XXkxC3QzqMClm 7dq4W0WrnGutsHzKx/833zcTwCLEu3YrTmvpOsT4JA5FpwjWWU0dVfiwROacn1Oe32bm 9hbQ== X-Gm-Message-State: AOAM532oJhB77X/5NcwUnuM3+jtoWyAC6X7cZ1saSAJ+oytr1T1Bb6o8 FeQHbim3Nm5SSnkdl7YzCNBpmbzUxGmlqrBPzXc= X-Google-Smtp-Source: ABdhPJx2j+WLRuHx6rpO7Dl95/n6zjxwt0lx2dBVqcmN8p1lNQkuRQtrCf4t+2gbUw7UgAe8w7av6kvka5elU3LTjus= X-Received: by 2002:a05:6602:490:b0:65d:cfc5:9221 with SMTP id y16-20020a056602049000b0065dcfc59221mr10786278iov.0.1652812962454; Tue, 17 May 2022 11:42:42 -0700 (PDT) MIME-Version: 1.0 References: <20220515064126.1424-1-linux.amoon@gmail.com> <20220515064126.1424-2-linux.amoon@gmail.com> <6a6ed76a-50fa-2b05-896e-8936d3c3f597@linaro.org> In-Reply-To: <6a6ed76a-50fa-2b05-896e-8936d3c3f597@linaro.org> From: Anand Moon Date: Wed, 18 May 2022 00:12:27 +0530 Message-ID: Subject: Re: [PATCHv2 1/6] thermal: exynos: Enable core tmu hardware clk flag on exynos platform To: Krzysztof Kozlowski Cc: Bartlomiej Zolnierkiewicz , "Rafael J. Wysocki" , Daniel Lezcano , Amit Kucheria , Zhang Rui , Alim Akhtar , Linux PM list , linux-samsung-soc@vger.kernel.org, linux-arm-kernel , Linux Kernel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220517_114245_470407_8784C6D9 X-CRM114-Status: GOOD ( 27.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Krzysztof, On Sun, 15 May 2022 at 15:22, Krzysztof Kozlowski wrote: > > On 15/05/2022 08:41, Anand Moon wrote: > > Use clk_prepare_enable api to enable tmu internal hardware clock > > flag on, use clk_disable_unprepare to disable the clock. > > > > Cc: Bartlomiej Zolnierkiewicz > > Signed-off-by: Anand Moon > > Here as well you ignored my first comment: > https://lore.kernel.org/lkml/CANAwSgS=08fVsqn95WHzSF71WTTyD2-=K2C6-BEz0tY0t6A1-g@mail.gmail.com/T/#mbfc57b40a7ed043dd4d4890bedb6bad8240058cd > > "This is not valid reason to do a change. What is clk_summary does not > really matter. Your change has negative impact on power consumption as > the clock stays enabled all the time. This is not what we want... so > please explain it more - why you need the clock to be enabled all the > time? What is broken (clk_summary is not broken in this case)?" > Ok, I fall short to understand the clock framework. > This was not addressed, you just resent same code... > Thanks for the review comment. Here is the Exynos4412 user manual I am referring to get a better understanding of TMU drivers [0] https://chasinglulu.github.io/downloads/SEC_Exynos4412_Users%20Manual_Ver.1.00.00.pdf Exynos Thermal is controlled by CLK_SENSE field is toggled on/off by the TMU for rising and falling temperatures which control the interrupt. TMU monitors temperature variation in a chip by measuring on-chip temperature and generates an interrupt to CPU when the temperature exceeds or goes below pre-defined threshold. Instead of using an interrupt generation scheme, CPU can obtain on-chip temperature information by reading the related register field, that is, by using a polling scheme. tmu clk control the CPU freq with various power management like DVFS and MFC so this clk needs to be *enabled on*, If we use clk_prepare_enable API we enable the clk and the clk counters, I check the call trace of the *clk_prepare_enable* [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/clk.h?h=v5.18-rc7#n945 it first calls *clk_prepare* and then *clk_enable* functions to enable the clock and then the hardware flag gets enabled for the clock I also check the call trace of the *clk_prepare* below [2} https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk.c?h=v5.18-rc7#n943 it does not enable the clk explicitly but prepares the clock to be used. "clk_prepare can be used instead of clk_enable to ungate a clk if the operation may sleep. One example is a clk which is accessed over I2c. In the complex case a clk ungate operation may require a fast and a slow part. It is this reason that clk_prepare and clk_enable are not mutually exclusive. In fact clk_prepare must be called before clk_enable. Returns 0 on success, -EERROR otherwise." What it means is we still need to call *clk_enable* to enable clk in the drivers and *clk_disable* to disable within the driver. In exynos tmu driver uses many clk_enable and clk_disable to toggle the clock which we can avoid if we used the switch to used *clk_prepare_enable* function in the probe function. [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/samsung/exynos_tmu.c?h=v5.18-rc7#n259 [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/samsung/exynos_tmu.c?h=v5.18-rc7#n350 [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/samsung/exynos_tmu.c?h=v5.18-rc7#n653 [6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/samsung/exynos_tmu.c?h=v5.18-rc7#n731 Locally I remove these function calls of clk_enable/ clk_disable function calls in the driver with these changes, stress-tested did not find any lockup. Please correct me if I am wrong. > > Best regards, > Krzysztof Thanks & Regards -Anand _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel