On Fri, 25 Oct 2024 at 09:46, Sibi Sankar <quic_sibis@xxxxxxxxxxx> wrote: > > > > On 10/25/24 11:44, Dmitry Baryshkov wrote: > > 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. > > That was a qualcomm specific driver and hence we could do such > kind of filtering. This however is the generic scmi perf protocol > and it's not something we should ever consider introducing :/ This depends on the maintainer's discretion. > > > > >> > >>> > >>> [ 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? > > They are sure to trickle out but I guess it's upto the oem > to decide if they do want to pick these up like some of the > other firmware updates being tested only on CRD. Not sure why > warnings duplicates should block cpufreq from landing for x1e > but if that's what the community wants I can drop reposting > this series! No, the community definitely wants to have cpufreq for X1E. But at the same time some reviewers prefer to have a warning-free boot if those warnings can't be really fixed. I don't have such a strict position, but I'd prefer to see those messages at dev_info or dev_dbg level. Also, can we please have some plan or idea if somebody is actually working with laptop vendors to get corresponding firmware updates onto their hardware? -- With best wishes Dmitry
