Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp340840imm; Wed, 18 Jul 2018 03:08:07 -0700 (PDT) X-Google-Smtp-Source: AAOMgpea28h8ePEm5eRADlIWVGGQGMP6oFcdwqi+vJZI84TovdLASg8WJ+PCmR3eyGH2DxRxZxxB X-Received: by 2002:a62:4f5b:: with SMTP id d88-v6mr4546188pfb.225.1531908486937; Wed, 18 Jul 2018 03:08:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531908486; cv=none; d=google.com; s=arc-20160816; b=JL7hyK5rTIqRs+txt9LLbWfjqHkU3dyTZc1o/9pd7KjzNBRcC72kgyp+aodGZweRy8 fqgFYFVm/zDklrbqLPqsPLE/9/3aPsz32sxKlpLKPJ+s4GextshGfM/P/Yx2diVAcUPI ppY6UB5526oxYOVpn27hwy1Ss1pUNkm08u9Bl/oXvptAZr+IE92E8jwjFk+ARaO7+QC1 wAZAISuIbfLUARsOIMaStat0Y2slHDmFSddfLRR+LDJwd6FeIEcMXlxdO/llQ0QEW128 vhtI89VSq7/GDLW5IsxaVB6CZdLqEUWnll35lJCISSRG/4X+MGLt6UGMe5OpaUpP6oGG fPbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=EZ2h/NecK0wfNWOC2THFmcQqLnuUY/coB/i4Q4WPHtM=; b=KmAcFPTlvLcEBxYBnj2UFDegeuZXABguIgJ/VR5oDHA6VsoO+bwKnI7ZgX4pYgJ0Tz V1p2oiNHAT6v7oy+QGxExBU1OLXfusNEWthf6Wh2J23mPXvLmIRn4oKOyZJbujpesRTa xMT/jIqeeoXC7UQqJvLooay9sUANgmby69FMz9vewJ+BarJfK60bkGC0MVyD1FkIGcsc 4WvfG1jzb0EpWsywqf7es4tCzN2k1vm8uMcqVi93ZHgdibDWpmpOqs3SnIOA/wIErRmq SeswKNSnhieveXYv+eIbUJGw6LCaRrvHwnXu77OlLoadQM2Lz92cflFLXnHXznG1qYxE a84A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WB4bkBeI; 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 j17-v6si3009539pfj.104.2018.07.18.03.07.52; Wed, 18 Jul 2018 03:08:06 -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=pass header.i=@kernel.org header.s=default header.b=WB4bkBeI; 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 S1730749AbeGRKoI (ORCPT + 99 others); Wed, 18 Jul 2018 06:44:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:51374 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726402AbeGRKoH (ORCPT ); Wed, 18 Jul 2018 06:44:07 -0400 Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D6C2420854; Wed, 18 Jul 2018 10:06:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1531908418; bh=XhOxADjsx32nUgQMfU+EpRByMBYl3lic4JtC9OoX5ow=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=WB4bkBeII1EAUyQsk8jlWujcRMWXaoK77rlvAU+lX4olIHC66ikZ5R8hDTI9+FhBQ SZZ48hPJ4IkGhLiuqtRvm1VCr7skdsXH+pPyw5MwiBNTugMVFeF+V15k0QfW2k8psa rbLpd+ksa7LKUA6OSVIYHx3g40gXF3lb47t7HVm8= Received: by mail-wm0-f50.google.com with SMTP id y22-v6so2258680wma.0; Wed, 18 Jul 2018 03:06:57 -0700 (PDT) X-Gm-Message-State: AOUpUlEeCvUeMkug9J/p1T4ix4SxDJb5bXkfbctVAF84S7Lp1SaB3CuM m3qf5DPgJWNK0gUin8UAUb8hN2I2Eu86jNAGKuI= X-Received: by 2002:a1c:3a8f:: with SMTP id h137-v6mr1205290wma.72.1531908416374; Wed, 18 Jul 2018 03:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:9141:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 03:06:55 -0700 (PDT) In-Reply-To: References: <1531822342-4293-1-git-send-email-linux.amoon@gmail.com> From: Krzysztof Kozlowski Date: Wed, 18 Jul 2018 12:06:55 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/5] thermal: exynos: enable core tmu clk on exynos platform To: Anand Moon Cc: Bartlomiej Zolnierkiewicz , Zhang Rui , Eduardo Valentin , Kukjin Kim , Rob Herring , Mark Rutland , Linux PM list , "linux-samsung-soc@vger.kernel.org" , linux-arm-kernel , Linux Kernel , devicetree Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18 July 2018 at 11:24, Anand Moon wrote: > Hi Krzysztof > > On 18 July 2018 at 11:47, Krzysztof Kozlowski wrote: >> On 17 July 2018 at 22:23, Anand Moon wrote: >>> Hi Krzysztof >>> >>> On 17 July 2018 at 17:50, Krzysztof Kozlowski wrote: >>>> Hi Anand, >>>> >>>> Thanks for patch. >>>> >>>> On 17 July 2018 at 12:12, Anand Moon wrote: >>>>> clk_summary do not show tmu_apbif clk enable, so replace >>>>> the clk_prepare with clk_prepare_enables to enable tmu clk. >>>> >>>> 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)? >>>> >>> >>> Opps I could not explain some more in my commit message. >>> >>> Actually TMU sensor for Exynos process are controlled by so external clk >>> >>> Exynos4412 have VDD18_TS sensor which controls the CLK_SENSE tmu. >>> Exynos5422 have VDD18_TS01 / VDD18_TS23 / VDD18_TS4 sensor which >>> control the CLK_SENSE tmu. >>> >>> So as per my understanding tmu is clk driver which control the flow PMIC. >>> >>> clk_prepare_enable combine clk_prepare and clk_enable >>> and clk_disable_unprepare combine clk_disable and clk_unprepare. >>> >>> most of the driver prefer clk_prepare_enable and clk_disable_unprepare. >>> >>> clk_summary is just a reference looking point where we could check the >>> clk is enable/disable. >>> >>> what is broken ? >>> I still few more parameter need to tuned to configure the tmu driver. >> >> I am sorry but I am still unable to see what is broken and what are >> you trying to fix. I asked what is broken and you replied that there >> is a sensor, there is a clock, drivers use clk_prepare_enable and some >> more parameter need to be tuned... None of these are answers to >> question - what is broken. How can I reproduce the problem? >> >> Best regards, >> Krzysztof > > Basically I use thermal testing. > > # git clone https://git.linaro.org/power/pm-qa.git > # cd pm-qa > # make -C thermal check > > most of the testcase failed on Exynos5422 but some pass on Exynos4412. > > Attach is the software overview from Exynos5422 user manual. > > I am not able to explain in deep technically, but I have studied other thermal > driver to draw into conclusion that tmu clk's need to be enabled. That is true in general - the clk has to be enabled in certain cases. However you did not say at all when you want this clock to be enabled... and the your patch enables it for entire lifetime of device. > If you feel the we should not enable these clk, them I will drop the > clk_prepare_enable check > and resubmit the changes with better commit message. I don't know. This was fifth email in this thread and it is the first time some real problem is mentioned. Still the issue is not described entirely so I really do not have a clue whether this patch fixes something or not. What is more, you mentioned falling pm-qa tests here (not in commit msg) but did not say whether this patch fixes anything or not. So let me summarize it: 1. You did not describe the problem you want to fix. 2. The patch looks incorrect because it enables the clock for entire lifetime of device which we do not want. 3. The patch might or not might fix some problem. We even do not know what... 4. The clock not being enabled when not needed... is obviously not a problem. Please start from beginning. Find the problem, tell us how it can be reproduced and deliver a single patch which fixes the problem. This pattern of your code - fixing something without describing the problem - happened many time before. I repeated this some times before as well. I would prefer not to repeat to many times. Therefore I would be happy if you follow the path mentioned in paragraph before always: find the problem, tell how it can be reproduced, deliver single patch which fixes the problem. Best regards, Krzysztof