On Fri, Oct 25, 2024 at 11:38:36AM +0530, Sibi Sankar wrote: > > > On 10/23/24 21:56, Johan Hovold wrote: > > On Wed, Oct 23, 2024 at 01:16:47PM +0530, Sibi Sankar wrote: > > > On 10/10/24 20:32, Johan Hovold wrote: > > > > On Mon, Oct 07, 2024 at 11:36:38AM +0530, Sibi Sankar wrote: > > > > > The series addresses the kernel warnings reported by Johan at [1] and are > > > > > are required to X1E cpufreq device tree changes [2] to land. > > > > > > > > > > [1] - https://lore.kernel.org/lkml/ZoQjAWse2YxwyRJv@xxxxxxxxxxxxxxxxxxxx/ > > > > > [2] - https://lore.kernel.org/lkml/20240612124056.39230-1-quic_sibis@xxxxxxxxxxx/ > > > > > > > > > > The following warnings remain unadressed: > > > > > arm-scmi arm-scmi.0.auto: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16 > > > > > arm-scmi arm-scmi.0.auto: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16 > > > > > > > > Are there any plans for how to address these? > > > > > Sorry missed replying to this. The error implies that duplicate > > > opps are reported by the SCP firmware and appear once during probe. > > > > I only see it at boot, but it shows up four times here with the CRD: > > https://lore.kernel.org/lkml/d54f6851-d479-a136-f747-4c0180904a5e@xxxxxxxxxxx/ > > As explained ^^, we see duplicates for max sustainable performance twice > for each domain. If existing products were shipped with the firmware that lists single freq twice, please filter the frequencies like qcom-cpufreq-hw does. > > > > > [ 8.098452] arm-scmi arm-scmi.0.auto: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16 > > [ 8.109647] arm-scmi arm-scmi.0.auto: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16 > > [ 8.128970] arm-scmi arm-scmi.0.auto: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16 > > [ 8.142455] arm-scmi arm-scmi.0.auto: Failed to add opps_by_lvl at 3417600 for NCC - ret:-16 > > > > > This particular error can be fixed only by a firmware update and you > > > should be able to test it out soon on the CRD first. > > > > Can you explain why this can only be fixed by a firmware update? Why > > can't we suppress these warnings as well, like we did for the other > > warnings related to the duplicate entries? > > > > IIUC the firmware is not really broken, but rather describes a feature > > that Linux does not (yet) support, right? > > We keep saying it's a buggy firmware because the SCP firmware reports > identical perf and power levels for the additional two opps and the > kernel has no way of treating it otherwise and we shouldn't suppress > them. Out of the two duplicate opps reported one is a artifact from how > Qualcomm usually show a transition to boost frequencies. The second opp > which you say is a feature should be treated as a boost opp i.e. one > core can run at max at a lower power when other cores are at idle but > we can start marking them as such once they start advertising their > correct power requirements. So I maintain that this is the best we > can do and need a firmware update for us to address anything more. Will existing shipping products get these firmware updates? -- With best wishes Dmitry
