From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA155C432C0 for ; Tue, 3 Dec 2019 15:44:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7EDA62070A for ; Tue, 3 Dec 2019 15:44:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727030AbfLCPow (ORCPT ); Tue, 3 Dec 2019 10:44:52 -0500 Received: from muru.com ([72.249.23.125]:44012 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726098AbfLCPow (ORCPT ); Tue, 3 Dec 2019 10:44:52 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id E047F804F; Tue, 3 Dec 2019 15:45:28 +0000 (UTC) Date: Tue, 3 Dec 2019 07:44:47 -0800 From: Tony Lindgren To: "H. Nikolaus Schaller" Cc: Nishanth Menon , Discussions about the Letux Kernel , Linux Kernel Mailing List , Tero Kristo , =?utf-8?B?QW5kcsOp?= Roth , Andreas Kemnade , Linux-OMAP , Adam Ford , arm-soc Subject: Re: [PATCH] ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage() Message-ID: <20191203154447.GC35479@atomide.com> References: <20190924233222.52757-1-tony@atomide.com> <8FFD44DB-73F8-4807-91E1-C97DA8F781BA@goldelico.com> <20191202213929.GB35479@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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 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. Regards, Tony