From patchwork Tue Nov 6 01:29:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Niklas Cassel X-Patchwork-Id: 150235 Delivered-To: patch@linaro.org Received: by 2002:a2e:299d:0:0:0:0:0 with SMTP id p29-v6csp3307099ljp; Mon, 5 Nov 2018 17:29:36 -0800 (PST) X-Google-Smtp-Source: AJdET5eRtqYYuDNADGR0ev5SPWx18fj3JDONqE22vYaIjiw1e9d4Bk0xYPhXFsLOo4LFcFjaAYaB X-Received: by 2002:a63:e445:: with SMTP id i5mr19353381pgk.307.1541467776016; Mon, 05 Nov 2018 17:29:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541467776; cv=none; d=google.com; s=arc-20160816; b=ECsO0grO/T8dZrFoawefNB2cbi29rtFUpm7Ewas5Hkp6OWjD0XZw9ePNpknxv0w1yY 35e6nCzxdR2LToujdD5npF+gY0F9NucICwuuRceeBXoNYXTSAUTEukvxkf43OXeodHyS nVjEtRpy8N3R0njiVbWlraTRlp21UyoDI4yAQbQ86Dpk+Pvikf5WRu6i2hfHFar/rnaM tBILUYQ0hZ8qEnYAF5y1xW4EYRMYIyD/nE4u1vVOfH0TcVOv+OcsljJ1uqC4TI/mDko2 JTzfcg7fLlsE7rlPhfBxYCkDgJo//S5ZXXEVi0HxV1b78UTefmoJ4JoT9YFWMgm0Lnmn 5C0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature; bh=1e3I/KDnanvN9kwto57/PKEf+Ws+74tzdDp4sUDSZN8=; b=hlMjabuMJcVFGx4SnBpHT00qIxiPyfJPSNu1jTxf4FJ1orB9TTn2ojW22MoYFCFL6M rgYi8UXi//rJjGgeXCDeTpYQTP5ylI58IxPTK7V9LPai/ESRaUC/OLc9AXe/WqWqFHUK HMERUo+Om7gAcZSEp7TWojv5tRCPwAyaOE2JRvpF96QWBHY5yF5ND4HZcGIRzC34uUhT 4efMoSGbzNeGM5arXii8AIjL5OCEDCjJNkmY5Ss1PGJupJSFx4ghVkRL60aad9dM94Ol HtiVpeLFyuTN4h7ss737lg8EFF+gUIexaThGO+GJBy0v50eOdXMe9fSwNZhy/jepDKX7 IXUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MVfGqJde; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si17431606pgs.8.2018.11.05.17.29.35; Mon, 05 Nov 2018 17:29:36 -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=pass header.i=@linaro.org header.s=google header.b=MVfGqJde; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727435AbeKFKwK (ORCPT + 32 others); Tue, 6 Nov 2018 05:52:10 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:46011 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726092AbeKFKwK (ORCPT ); Tue, 6 Nov 2018 05:52:10 -0500 Received: by mail-lf1-f67.google.com with SMTP id b20so7602069lfa.12 for ; Mon, 05 Nov 2018 17:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=1e3I/KDnanvN9kwto57/PKEf+Ws+74tzdDp4sUDSZN8=; b=MVfGqJdeyXJoIVT0PZ1gVIewHUjg77kUJNNYFPLWx502B/3kHWbdb7jcxEOab6iUgV v700n82DYM1EroUcjoTO7vU33H8Zq0nYsm3UctCUtNR6bF24pJMmgHLWHlYMZDTaHvbS QpUl3IM8jUpwFqcEbWe1zfC+WVqqgSnSk+vis= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=1e3I/KDnanvN9kwto57/PKEf+Ws+74tzdDp4sUDSZN8=; b=DRfleRnPt2kSetmhMiYI6hBBOOAriRSdZwSQ9tkdMCCvPb91qBHNRZFp4NprQBX142 xQN8rsm9NJW2U7EThGGePxg+l6dbeF7y1MTalWd7VpNYHpAXI0cQgHw4wYz0A3clCU+0 Fjz9gJvzIj0L+0ht4Ewpkhqoj7cSAjq0JOspftvOqOEu6RbbkvlUjfGvwW/1Ff6K2imp wVPoDnhsmhDSNTkw5jk9uDIYO+r0dpW6RrMHinkaLJ5YKmbg6TrcRDavrupgAz6ZOG1+ Vsw+T9lPJiYXFYp6SlqapjnRlLJL9lsLZaTJFMsCyE3QwYoiwo8+dkBs3xlqF6f+tjqN L4Kg== X-Gm-Message-State: AGRZ1gJyYen4ALHerh86pL2R1tMz9zgm6N7W/5RBDGXspcydx1HpHdKn Xy3dcoAvHKuhO4YTF0jnk20b9g== X-Received: by 2002:a19:982:: with SMTP id 124mr8008351lfj.138.1541467771494; Mon, 05 Nov 2018 17:29:31 -0800 (PST) Received: from centauri.lan (h-229-118.A785.priv.bahnhof.se. [5.150.229.118]) by smtp.gmail.com with ESMTPSA id j126sm519697lfe.10.2018.11.05.17.29.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 05 Nov 2018 17:29:30 -0800 (PST) Date: Tue, 6 Nov 2018 02:29:28 +0100 From: Niklas Cassel To: bgolaszewski@baylibre.com Cc: srinivas.kandagatla@linaro.org, viresh.kumar@linaro.org, linux-kernel@vger.kernel.org Subject: [regression 4.20-rc1, bisected] cpufreq fails to register on db820c Message-ID: <20181106012928.GA32044@centauri.lan> MIME-Version: 1.0 Content-Disposition: inline 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 Hello Bartosz, I've run into a regression on v4.20-rc1, where cpufreq on dragonboard 820c fails to register. I've bisected the issue to: e888d445ac33 ("nvmem: resolve cells from DT at registration time") If I revert that patch, cpufreq starts working on dragonboard 820c again. Before your patch: [ 5.052985] qcom_cpufreq_kryo_probe:110 speedbin_nvmem: ffff8000d4d51e00 [ 5.053133] qcom_cpufreq_kryo_probe:120 speedbin: ffff8000d4d51d00 [ 5.058895] qcom_cpufreq_kryo_probe:121 *speedbin: 0 After your patch: [ 4.791664] qcom_cpufreq_kryo_probe:110 speedbin_nvmem: ffff8000d472ed00 [ 4.791815] qcom_cpufreq_kryo_probe:120 speedbin: ffff8000d451b300 [ 4.797575] qcom_cpufreq_kryo_probe:121 *speedbin: 12 The prints are debug prints that I've added locally: So it appears that the read from nvmem_cell_read() gets another value after your commit. This value is then given to dev_pm_opp_set_supported_hw(), however, since this new value (12) from nvmem_cell_read() doesn't have any matching opp-supported-hw in device tree, cpufreq fails to register. This error only happens when we read this new incorrect value (12 instead of 0). Any idea why nvmem_cell_read() returns a new value for the same efuse? Kind regards, Niklas Tested-by: Niklas Cassel --- a/drivers/cpufreq/qcom-cpufreq-kryo.c +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c @@ -107,6 +107,7 @@ static int qcom_cpufreq_kryo_probe(struct platform_device *pdev) } speedbin_nvmem = of_nvmem_cell_get(np, NULL); + pr_err("%s:%d speedbin_nvmem: %lx\n", __func__, __LINE__, speedbin_nvmem); of_node_put(np); if (IS_ERR(speedbin_nvmem)) { if (PTR_ERR(speedbin_nvmem) != -EPROBE_DEFER) @@ -116,6 +117,8 @@ static int qcom_cpufreq_kryo_probe(struct platform_device *pdev) } speedbin = nvmem_cell_read(speedbin_nvmem, &len); + pr_err("%s:%d speedbin: %lx\n", __func__, __LINE__, speedbin); + pr_err("%s:%d *speedbin: %u\n", __func__, __LINE__, (unsigned int)(*speedbin)); nvmem_cell_put(speedbin_nvmem); if (IS_ERR(speedbin)) return PTR_ERR(speedbin);