On Fri, 25 Oct 2024 at 13:29, Cristian Marussi <cristian.marussi@xxxxxxx> wrote: > > On Fri, Oct 25, 2024 at 01:11:37PM +0300, Dmitry Baryshkov wrote: > > 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. > > I think dev_info could be an option from the SCMI perspective (as per my > other mail), the important thing in these regards is to NOT go > completely silent against fw anomalies...to avoid the the risk of being > silently ignored .... I'll see what Sudeep thinks about... Absolutely. SCMI layer knows that such a problem might exist and knows how to handle it, so it should bug the user in a polite way. -- With best wishes Dmitry
