linux-kernel - Re: [PATCH] ARM: OMAP2+: Fix warnings with broken omap2_set_init

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5F430C0D-7F25-4680-87B9-2D65A08A9F83@goldelico.com>
Date:   Tue, 3 Dec 2019 16:58:21 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>, Nishanth Menon <nm@...com>,
        Tero Kristo <t-kristo@...com>
Cc:     Discussions about the Letux Kernel <letux-kernel@...nphoenux.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        André Roth <neolynx@...il.com>,
        Andreas Kemnade <andreas@...nade.info>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Adam Ford <aford173@...il.com>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()


> Am 03.12.2019 um 16:44 schrieb Tony Lindgren <tony@...mide.com>:
> 
> * H. Nikolaus Schaller <hns@...delico.com> [191203 12:31]:
>> Ok, dev_pm_opp_find_freq_ceil() is doing what it should do and it
>> returns the first OPP higher or equal than the frequency passed in.
>> 
>> The real reason for the warning is that the same OPP table is used
>> for vdd_mpu_iva and vdd_core and it appears as if "core" (l3_ick)
>> runs at 200 MHz which does not correspond to a valid OPP.
> 
> OK
> 
>> So to silcence the warning it suffices to remove
>> 
>> 	omap2_set_init_voltage("core", "l3_ick", "l3_main");
>> 
>> The question is now what l3_ick has to do with the OPPs at all
>> and how it should interwork with OPPs and cpufreq.
> 
> So what changed then for iva in your configuration then?
> 
> At least I'm getting errors for both for 34xx and dm3730 with
> Linux next and reverted commit cf395f7ddb9e ("ARM: OMAP2+: Fix
> warnings with broken omap2_set_init_voltage()"):
> 
> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva
> omap2_set_init_voltage: unable to set vdd_mpu_iva
> omap2_set_init_voltage: unable to find boot up OPP for vdd_core
> omap2_set_init_voltage: unable to set vdd_core

Hm... Is there maybe a dependency on u-boot?

We are using a quite old version which may boot with vdd_mpu_iva
as 300 MHz while yours may have a different clock.

What we could do is augment the printk (or dev_err) to tell
in these warnings what it is looking for...

	opp = dev_pm_opp_find_freq_ceil(dev, &freq);
	if (IS_ERR(opp)) {
		pr_err("%s: unable to find boot up OPP for vdd_%s freq %ulHz\n",
		__func__, vdd_name, freq);
		goto exit;
	}

> Then for fixing this code, seems like this can all happen from
> a regular device driver init based on the dts data.. We've had
> PM init completely ignore these errors already for years so
> whatever dependency there might be seems non-critical :)
> 
>> Or does all this mean we may need a second OPP fable for vdd_core
>> and 200 MHz? But what would it be good for? I have not seen any
>> reference for "core-OPPs" in the TRM.
> 
> OK yeah sounds like all the domains need an opp table.
> 
> Also, I recall some SoCs having a dependency between having to
> run DSP at a lower rate for higher MPU rates, not sure if omap3
> has such dependencies though.

Well, I not aware of documentation of such dependencies and there
is also some confusion what vdd_mpu_iva exactly is and what vdd_core is.
twl4030 has vdd1 and vdd2 but their relationship isn't clear either.

Maybe Tero or Nisanth can clarify?

BR and thanks,
Nikolaus