Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1489472ybl; Tue, 3 Dec 2019 07:59:34 -0800 (PST) X-Google-Smtp-Source: APXvYqwx0LHr2RGApU+bH3sHfez/dtTodCsc5fX8r1zPBdPklsCgy1WnmJw5vdIVKjyfPM625WDI X-Received: by 2002:a9d:730e:: with SMTP id e14mr3484178otk.62.1575388774194; Tue, 03 Dec 2019 07:59:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575388774; cv=none; d=google.com; s=arc-20160816; b=mVHYA+drLxmYt9n7/tLRr8EYZ1b5sMCYNZLEgN/DEPZuXApmhEpN0tcGLYsL4j+TwT iiPCRhYnGMPOhwm+EFN4ALs+IWtEbQwp/S6TsV1SnoRXkXLTwkgG6HyaYVi1yCSkSBWT mst+uFqY4StpLy6bXteBJtW+FSO4z4VbwDdbB7PT0NnNEbwWdXoqpVmfvZ6fJT6v3gvX nf9xRfptPdHlcuINFas0h9NQGzB09kvBeYdXRCuqkc2icdy7Y2Q8LOue1BLx4aOKWlW2 FapxdFFYl5IoLY7fs3jZkxHf8GeZlxlXnBhNfdyUSO5RtCUwN3Bizi96ik97t2Eqxtku ntfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=rtHOM2pr5THkPaPjFp7PY8/XZ2kRx7eA36g2+Jz6rs8=; b=sA9HcCDMvEJ2gc1zrTWel5G81Q7jxkOkMJEKOANw3NP6lJHD3BbF0slmQQ3Bp8VBnt rEno5N+AKvCcKzLUFFFPCfZY8b27y979vESp3RurdaEh4NtQGRhDXTtmGqHZjEg2WgpT Etr32KygZ1Rzkb+gBCmN4fgCbuwetHR32bgaCGmNFPqE7/+uvBd23nThd52XOfB61OS/ 8mGWvnAci3M/ql9CGP4zq6/gIrLSOoj7DjDcc3PG7H2gU0CV0JnwEVuaSK0i9mNZxZLq oxXkItItgh8fvJK0hTG954io3F0xjMz9/6YDigLjOuZZECCOJpXNkJMf9YW7mwxcg1xr 0GyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@goldelico.com header.s=strato-dkim-0002 header.b="C7GNhl/U"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j15si1455105oij.52.2019.12.03.07.59.21; Tue, 03 Dec 2019 07:59:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@goldelico.com header.s=strato-dkim-0002 header.b="C7GNhl/U"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726673AbfLCP6u (ORCPT + 99 others); Tue, 3 Dec 2019 10:58:50 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([81.169.146.164]:30871 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726105AbfLCP6t (ORCPT ); Tue, 3 Dec 2019 10:58:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1575388727; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=rtHOM2pr5THkPaPjFp7PY8/XZ2kRx7eA36g2+Jz6rs8=; b=C7GNhl/UgmjUSWvDbo18nGNiLcM72NgHLP6z2q6nbdL5kWAFuSDo9ToDAwfEb305YK UMUf4CW5n7AEOPeTTUszVhhHG/AaYZ9inxCIQy2UpiPru/VGD+yUXfwinShHGo1HyvSt J2wxOGRdrao/saA1Hb7xOBpwFuYzm9fdxTz85MDjZ9JxyQU7J6V0rONJHcNcwVmQDHZ4 XfknovXYa3cfGO9XLPfMWZSecdb8aO3DtZsQEbGEhI4k7RiGQxRBy54dNtUxYRQY3Kea zckJgwoxTRmUoVzX1NolnMjdyFJdjyCl8UM4N480YFT/ZkPPt5S/O3tgpX6eV/TPGsJw BU+g== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBp5hRw/qOxWRk4dCyiod0h4YszmWBgQhXwA+mYqVRc/0ppp+PaXh4=" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:16b8:2678:d200:b5c8:3e51:552:ff8c] by smtp.strato.de (RZmta 46.0.2 AUTH) with ESMTPSA id 6067eavB3FwB6R5 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Tue, 3 Dec 2019 16:58:11 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH] ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() From: "H. Nikolaus Schaller" In-Reply-To: <20191203154447.GC35479@atomide.com> Date: Tue, 3 Dec 2019 16:58:21 +0100 Cc: Discussions about the Letux Kernel , Linux Kernel Mailing List , =?utf-8?Q?Andr=C3=A9_Roth?= , Andreas Kemnade , Linux-OMAP , Adam Ford , arm-soc Content-Transfer-Encoding: 7bit Message-Id: <5F430C0D-7F25-4680-87B9-2D65A08A9F83@goldelico.com> References: <20190924233222.52757-1-tony@atomide.com> <8FFD44DB-73F8-4807-91E1-C97DA8F781BA@goldelico.com> <20191202213929.GB35479@atomide.com> <20191203154447.GC35479@atomide.com> To: Tony Lindgren , Nishanth Menon , Tero Kristo X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Am 03.12.2019 um 16:44 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [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