From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C79F34A0C; Mon, 6 Jan 2025 14:57:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736175453; cv=none; b=fWJT9RWQ7O1/YW71jikTMlsEffP5jN0OMXRuh+MO7RLFULxdaS/RogoI81Yt3ILfTH80YE5hBuHjnZDivPVjb40ow7ECfS9d/Dvj0poq+QncvtwrYQsGnZ5NLuVXduzIv2/GQp7tjK1URvsz0wMzmxNy1kPa02joJu+WivMQ8ac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736175453; c=relaxed/simple; bh=OH6QCFJFnQueFS8FvFwjI38w2sHTXla5+8K0Yq1gBak=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=qTj78IV5eOeI/5muPMKhfEvrp/KJXgAM96MjlvZHYpLD1ZpzCEX4zH/bRWxHyMyFrF9+6X2/QlABNk39EIw4AHID3uRysoP/7/T3up9k8xaxHHoNDQ2G05nQoEuo5yBF8IL7ImDhx5lTchsgJ6S8Dq9ejM4Y7TbgGeJrVAKJkYg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hcwnCG1x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hcwnCG1x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32FCCC4CED6; Mon, 6 Jan 2025 14:57:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736175453; bh=OH6QCFJFnQueFS8FvFwjI38w2sHTXla5+8K0Yq1gBak=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hcwnCG1xXqBj3hdwVVk+8ofrSTw4FM8hqPb63ExoyqqKI/IjzAfdjdpx8k47PP/7Q vhpi79rHogDo4DFvAsYIyRxfz6sZhSpmPcREKyNsXsoj3heqv81E+JLVMhVkCpta3V 1DcB45xeMplnmc7IQXyzvNZq4FcEUFVD06xZRBKMVPLuw2SPzpGZxZmqijspI5JmXr x9v4pKfUx9pPTCvhscGYkLvxWbcb9xbuAAm4WtAv9ahYcjnxR5/BB7bgzW42YTexot VcFP80YHTyqNIwm5YShMi7Aj4jaQYOikPyWJVHoZ9OrOsbocYDwtZNvRDIL5yiJrxE V9vTqJReiVbIg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tUoXr-009SKl-1D; Mon, 06 Jan 2025 14:57:31 +0000 Date: Mon, 06 Jan 2025 14:57:29 +0000 Message-ID: <864j2couqu.wl-maz@kernel.org> From: Marc Zyngier To: Sibi Sankar Cc: Johan Hovold , , , , , , , , , , , , , , , , Subject: Re: [PATCH V7 0/2] qcom: x1e80100: Enable CPUFreq In-Reply-To: References: <20241030130840.2890904-1-quic_sibis@quicinc.com> <86plnf11yf.wl-maz@kernel.org> <86o72z10b6.wl-maz@kernel.org> <86ed3p1rdq.wl-maz@kernel.org> <0fd14fb1-736d-cf7f-128f-658bda0de583@quicinc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: quic_sibis@quicinc.com, johan@kernel.org, sudeep.holla@arm.com, cristian.marussi@arm.com, andersson@kernel.org, konrad.dybcio@linaro.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, dmitry.baryshkov@linaro.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, quic_rgottimu@quicinc.com, quic_kshivnan@quicinc.com, conor+dt@kernel.org, quic_nkela@quicinc.com, quic_psodagud@quicinc.com, abel.vesa@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 06 Jan 2025 12:22:48 +0000, Sibi Sankar wrote: > > > > On 12/5/24 21:16, Johan Hovold wrote: > > On Thu, Dec 05, 2024 at 04:53:05PM +0530, Sibi Sankar wrote: > >> On 11/5/24 23:42, Marc Zyngier wrote: > >>> On Tue, 05 Nov 2024 16:57:07 +0000, > >>> Johan Hovold wrote: > >>>> On Fri, Nov 01, 2024 at 02:43:57PM +0000, Marc Zyngier wrote: > > > >>>>> I wonder whether the same sort of reset happen on more "commercial" > >>>>> systems (such as some of the laptops). You expect that people look at > >>>>> the cpufreq stuff closely, and don't see things exploding like we are. > >>>> > >>>> I finally got around to getting my Lenovo ThinkPad T14s to boot (it > >>>> refuses to start the kernel when using GRUB, and it's not due to the > >>>> known 64 GB memory issue as it only has 32 GB) > >>> > >>> > >>> I know the feeling. My devkit can't use GRUB either, so I added a > >>> hook to the GRUB config to generate EFI scripts that directly execute > >>> the kernel with initrd, dtb, and command line. > >>> > >>> This is probably the worse firmware I've seen in a very long while. > >> > >> The PERF_LEVEL_GET implementation in the SCP firmware side > >> is the reason for the crash :|, currently there is a bug > >> in the kernel that picks up index that we set with LEVEL_SET > >> with fast channel and that masks the crash. I was told the > >> crash happens when idle states are enabled and a regular > >> LEVEL_GET message is triggered from the kernel. This was > >> fixed a while back but it will take a while to flow back > >> to all the devices. It should already be out CRD's. > >> > >> Johan, > >> Now that you are aware of the the limitations can we make > >> a call on how to deal with this and land cpufreq? > > > > As Marc said, it seems you need to come up with a way to detect and work > > around the broken firmware. > > The perf protocol version won't have any changes so detecting > it isn't possible :( This is just... baffling. Can this be checked against one of the strings contained in the DMI tables? > > > > > We want to get the fast channel issue fixed, but when we merge that fix > > it will trigger these crashes if we also merge cpufreq support for x1e. > > > > Can you expand the on the PERF_LEVEL_GET issue? Is it possible to > > implement some workaround for the buggy firmware? Like returning a dummy > > value? How exactly are things working today? Can't that be used a basis > > for a quirk? > > The main problem is the X1E firmware supports fast channel level get > but when queried it says it doesn't support it :|. The PERF_LEVEL_GET > regular messaging which gets used as a fallback has a bug which causes > the device to crash. So we either enable cpufreq only on platforms > that has the fix in place Again: how do we detect this? > or live with the warning that certain messages > don't support fast channel which I don't think will fly. I've also been > told the crash wouldn't show up if we have all sleep states > disabled. So we have the choice between crashing quickly, or sucking power like mad? Thanks, M. -- Without deviation from the norm, progress is not possible.