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 X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5F13C2D0BF for ; Tue, 10 Dec 2019 21:24:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B8352073B for ; Tue, 10 Dec 2019 21:24:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576013059; bh=iKHzYfg2mi5+rXn4bwwSLeTeA/Prirx9XvsHR+GrqNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=iP/QxUqyE0fsE4yzB9K4jyfeeVWG2yIuoGJveEWiN0LCLpLK5WOPyIKpEYGoTa2K0 RAMV239tDvZygv8pauc8Z0POUmMgGXh9h+SHuknYtZIp55IJtiK64cu7vK3AkdpcFG cFHH6Fxat605LeS6uYNGKOTI/+hD5sql8fVAS/A8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728877AbfLJVYO (ORCPT ); Tue, 10 Dec 2019 16:24:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:33036 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727500AbfLJVKz (ORCPT ); Tue, 10 Dec 2019 16:10:55 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (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 99D51246AE; Tue, 10 Dec 2019 21:10:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576012254; bh=iKHzYfg2mi5+rXn4bwwSLeTeA/Prirx9XvsHR+GrqNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B4sagRIvW9990KfUKB6onyejIIjyx/Xi3LNSViu1NLzmTPHrslZQizeYb0lUdOc7E bsvtQgtwhOsn2x5VF/JTf8zDKhVt8gJTFplzgB1bbshq+qaXxyeuS1EblgP/lvJsn/ K5kWwtJF77fnLA3YCVIsTcBbUE66aaJCyjNp8uQQ= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ondrej Jirman , Maxime Ripard , Viresh Kumar , Sasha Levin , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH AUTOSEL 5.4 201/350] cpufreq: sun50i: Fix CPU speed bin detection Date: Tue, 10 Dec 2019 16:05:06 -0500 Message-Id: <20191210210735.9077-162-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191210210735.9077-1-sashal@kernel.org> References: <20191210210735.9077-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org From: Ondrej Jirman [ Upstream commit c23734487fb44ee16c1b007ba72d793c085e4ec4 ] I have observed failures to boot on Orange Pi 3, because this driver determined that my SoC is from the normal bin, but my SoC only works reliably with the OPP values for the slowest bin. By querying H6 owners, it was found that e-fuse values found in the wild are in the range of 1-3, value of 7 was not reported, yet. From this and from unused defines in BSP code, it can be assumed that meaning of efuse values on H6 actually is: - 1 = slowest bin - 2 = normal bin - 3 = fastest bin Vendor code actually treats 0 and 2 as invalid efuse values, but later treats all invalid values as a normal bin. This looks like a mistake in bin detection code, that was plastered over by a hack in cpufreq code, so let's not repeat it here. It probably only works because there are no SoCs in the wild with efuse value of 0, and fast bin SoCs are made to use normal bin OPP tables, which is also safe. Let's play it safe and interpret 0 as the slowest bin, but fix detection of other bins to match this research. More research will be done before actual OPP tables are merged. Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver") Acked-by: Maxime Ripard Signed-off-by: Ondrej Jirman Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/sun50i-cpufreq-nvmem.c | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c b/drivers/cpufreq/sun50i-cpufreq-nvmem.c index eca32e443716c..9907a165135b7 100644 --- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c +++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c @@ -25,7 +25,7 @@ static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev; /** - * sun50i_cpufreq_get_efuse() - Parse and return efuse value present on SoC + * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value * @versions: Set to the value parsed from efuse * * Returns 0 if success. @@ -69,21 +69,16 @@ static int sun50i_cpufreq_get_efuse(u32 *versions) return PTR_ERR(speedbin); efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK; - switch (efuse_value) { - case 0b0001: - *versions = 1; - break; - case 0b0011: - *versions = 2; - break; - default: - /* - * For other situations, we treat it as bin0. - * This vf table can be run for any good cpu. - */ + + /* + * We treat unexpected efuse values as if the SoC was from + * the slowest bin. Expected efuse values are 1-3, slowest + * to fastest. + */ + if (efuse_value >= 1 && efuse_value <= 3) + *versions = efuse_value - 1; + else *versions = 0; - break; - } kfree(speedbin); return 0; -- 2.20.1