Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1112604ybh; Mon, 13 Jul 2020 09:38:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxL+OeClKnoZuTteRMX4yaFhWEESOKPQB6U2H3x5mX+Wp6sWiDQ7bN3nPohwkJMR3dBlJlv X-Received: by 2002:aa7:d692:: with SMTP id d18mr256542edr.73.1594658289150; Mon, 13 Jul 2020 09:38:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594658289; cv=none; d=google.com; s=arc-20160816; b=gkM96uE7F3LYMe/qVwa0SpT1c7R5MZRDhJoxJV4OFpZ46xKlQ+V8r8ARzutQ0bljKl e9lhbqLzasox5cR7ZJe47orbIs6TWwGrZooYp8PHHbR50BvzAj+aZUbUUX42l1H1wTnU KgNjCNvXnfop595UhauGK62ul9UkiLCQZW2Xblm1tKfKrD4pB1tzlRg0FmBsnnUw+KiZ vvsbePhKyIau29JLv4hm9hvDI42On04m+tBi2mYxeskhCVpaMCjoND3C9BicOcOPbrOI MYAlDct9hsmNe9Qhap1RLw2fo1iJRrbChx7moDeFxgFRyQYtYoFoeHyACu4KtBtp5RvK lfAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=j07fRsUya2Rkr0o3lWYTAHPyUTT7NzlNKWFyMy2w+FU=; b=nNp691J1nPWw5WacC9QSHh5BS41BQOv62IaoztoAUlqUvgtMzFgtzS2xWUZXxYIbf/ c9UrBq0O+mamwseR3PpnOwxL38291UsDQ+yB+YgbVedqk+888UO9bgQSP+78p9QmcX4J EI0Gm3VEuda8t9SHNwc2fKSN5txHXuamrcLzQIevXC6HSHIXN1itsHiAriJtKW4L4fQm TMQBIBErMtiMHnOYIRzXXM/2g7+IElCGym7KIesLErQAIDg2Nv9+k11yIkqzVgRf8iU9 Jp4NQgDSx/3GwR30e7Tr/jZLyPoHpCeklhEa85UicVXuMvEtkb0ESArOkqvd4tWfLTnf q+gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=B64PHnnm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si1171002edm.364.2020.07.13.09.37.44; Mon, 13 Jul 2020 09:38:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=B64PHnnm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730454AbgGMQhl (ORCPT + 99 others); Mon, 13 Jul 2020 12:37:41 -0400 Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:6947 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729969AbgGMQhk (ORCPT ); Mon, 13 Jul 2020 12:37:40 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 13 Jul 2020 09:37:26 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Mon, 13 Jul 2020 09:37:39 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Mon, 13 Jul 2020 09:37:39 -0700 Received: from [10.26.72.101] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 Jul 2020 16:37:38 +0000 Subject: Re: [PATCH 1/2] cpufreq: tegra186: Fix initial frequency To: Viresh Kumar CC: Thierry Reding , "Rafael J . Wysocki" , , References: <20200712100645.13927-1-jonathanh@nvidia.com> <20200713032554.cykywnygxln6ukrl@vireshk-i7> From: Jon Hunter Message-ID: <3d6091f2-6b04-185f-6c23-e39a34b87877@nvidia.com> Date: Mon, 13 Jul 2020 17:37:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200713032554.cykywnygxln6ukrl@vireshk-i7> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1594658246; bh=j07fRsUya2Rkr0o3lWYTAHPyUTT7NzlNKWFyMy2w+FU=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=B64PHnnmjFFJzm6tcGsqHpZuxv/g2nvXhUgeOJl2Vbd+GAiwAIHLWiM3cdlBb1DDp s6e9UVM3Vv3e+J2Otc1z73T2hyJcDOxxRhwdenoQqYuzGfXvvmKxiqhtmbgi60tmqp +Yjn6B1jZP2WdTmE2JczxR5P+243Ls+0ZE9lpJG0l+txfFhRFOupM3mpAq0CNmOYSW QR4kLrJPx9Z1LUQW3yiK7Vc9/+lWxMQnLpS5U3tgTIliil8Fx6Gdz3bGQFJddTjzex 3epeuegOs+m0eIdtMY3rrT5j6h54uubqQ+cOX7Qs4Q+dXs0HsTXpLaX5c2QR4QDnlc o/w3C6XcmPlkw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/07/2020 04:25, Viresh Kumar wrote: > On 12-07-20, 11:06, Jon Hunter wrote: >> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add >> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for >> Tegra186 but as a consequence the following warnings are now seen on >> boot ... >> >> cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 0 KHz >> cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 2035200 KHz >> cpufreq: cpufreq_online: CPU1: Running at unlisted freq: 0 KHz >> cpufreq: cpufreq_online: CPU1: Unlisted initial frequency changed to: 2035200 KHz >> cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 0 KHz >> cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to: 2035200 KHz >> cpufreq: cpufreq_online: CPU3: Running at unlisted freq: 0 KHz >> cpufreq: cpufreq_online: CPU3: Unlisted initial frequency changed to: 2035200 KHz >> cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 0 KHz >> cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to: 2035200 KHz >> cpufreq: cpufreq_online: CPU5: Running at unlisted freq: 0 KHz >> cpufreq: cpufreq_online: CPU5: Unlisted initial frequency changed to: 2035200 KHz >> >> Although we could fix this by adding a 'get' operator for the Tegra186 >> CPUFREQ driver, there is really little point because the CPUFREQ on >> Tegra186 is set by writing a value stored in the frequency table to a >> register and we just need to set the initial frequency. > > The hardware still runs at the frequency requested by cpufreq core here, right ? Yes. > It is better to provide the get() callback as it is also used to show the > current frequency in userspace. I looked at that and I saw that if the get() callback is not provided, the current frequency showed by userspace is policy->cur. For this device, policy->cur is accurate and so if we added the get() callback we essentially just going to return policy->cur. Therefore, given that we already know policy->cur, I did not see the point in adding a device specific handler to do the same thing. Cheers Jon -- nvpublic