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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 1805AC4740A for ; Mon, 9 Sep 2019 18:11:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C2ED821924 for ; Mon, 9 Sep 2019 18:11:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=goldelico.com header.i=@goldelico.com header.b="GGlcUb07" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405270AbfIISL1 (ORCPT ); Mon, 9 Sep 2019 14:11:27 -0400 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.53]:31021 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730049AbfIISL1 (ORCPT ); Mon, 9 Sep 2019 14:11:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1568052685; 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=T0u92L3DaiGAvp/L3DT0N2IIOq/jhYuL1EviDkLmgUQ=; b=GGlcUb07OgfgYiPVljCteSKG/foci+KLDKsArITTavnj9b+GYiV62uJ26f1bQVXusy 50tdecQndTvE9WEDBOvoRRL+valnxlitcCZggjO2b4X7ATh6NDrZELGBnbNzQWjTS3Ur EGV48KrwxGYNsWc28rbpEDuwXk9mmIfJMd9exs90Ogn8vs+lZw524wg4VPRuHr4j06KA dAgtvQ7h7FkbyvPNv5mu6ve3uqMV5Ny5GhIXtXpMfvT8n3R2DwLX7qxBnFrhkzOlVHKg Cdl2BwbLzzZNFDWWWJWMop8mt8Pon8aT5R3a2P3Z3I1YT5otsK4O53yYo+wfhhvxWiLn Iv5w== X-RZG-AUTH: ":JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw9iZeHmMnw4vkig==" X-RZG-CLASS-ID: mo00 Received: from imac.fritz.box by smtp.strato.de (RZmta 44.27.0 DYNA|AUTH) with ESMTPSA id u036f9v89IBDy5H (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 9 Sep 2019 20:11:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx From: "H. Nikolaus Schaller" In-Reply-To: Date: Mon, 9 Sep 2019 20:11:13 +0200 Cc: Adam Ford , =?utf-8?Q?Andr=C3=A9_Roth?= , Linux-OMAP , Discussions about the Letux Kernel , Linux Kernel Mailing List , Andreas Kemnade , Nishanth Menon Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C1EF64E-B33C-4BFA-A7D3-471DD1B9EE86@goldelico.com> <515048DE-138D-4400-8168-F2B7D61F1005@goldelico.com> <7B3D1D77-3E8C-444F-90B9-6DF2641178B8@goldelico.com> <87420DBD-770F-4C32-9499-A3AEA5876E8A@goldelico.com> <20190909163236.GP52127@atomide.com> To: Tony Lindgren 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 09.09.2019 um 18:54 schrieb H. Nikolaus Schaller = : >=20 > Hi Tony, >=20 >> Am 09.09.2019 um 18:32 schrieb Tony Lindgren : >>=20 >> Hi, >>=20 >> * H. Nikolaus Schaller [190909 14:57]: >>> Another question that came up by private mail from Andr=C3=A9 was if = we >>> should better disable the turbo OPPs of omap34xx and 36xx by default >>> (status =3D "disabled";) because there are concerns about = overheating >>> the chips and we have no thermal regulation like for omap4 & 5. >>>=20 >>> But this would mean that every board DTS would have to set it = explicitly >>> to "enabled". >>=20 >> Yes I started thinking about that too. I think there is a requirement >> to do the scaling via the voltage processor for the higher modes. >=20 > It depends on how you read the little footnotes... >=20 > Table 4-18. Processor Voltages Without SmartReflex: >=20 > =E2=80=A2 This table defines the safe VDD1 (vdd_mpu_iva) voltage = ranges to be used before using the SmartReflex AVS feature for OPPs = calibration. > =E2=80=A2 Values are defined when SmartReflexTM feature is = deactivated. They can be lower when SmartReflexTM is activated. > =E2=80=A2 OPP130 and OPP1G are not available above TJ of 90C. > =E2=80=A2 (6) OPP1G is a high performance operating point which = has following requirements: > =E2=80=A2 =E2=80=93 ABB LDO must be set to FBB (Forward = Body Bias) mode when switching to this OPP. It requires having a 1 F = capacitor connected to cap_vdd_bb_mpu_iva. > =E2=80=A2 =E2=80=93 AVS (Adaptive Voltage Scaling) = power technique must be used to achieve optimum operating voltage. >=20 > So I read this as: >=20 > * OPP130 and OPP1G should be guarded by 90=C2=B0C thermal framework > * OPP1G should also set the ABB LDO to FBB mode > * AVS does only reduce voltage levels (to save energy =3D heat =3D = problem) > * only if we want "optimum operating voltage" (read as: "lowest = possible voltage" =3D "highest energy saving") we must use AVS >=20 > I.e. we do not necessarily need AVS or SmartReflex or help from the > twl4030 (except for changing the voltage). >=20 >> And there needs to be some way to automatically change to a lower >> OPP in some cases. >=20 > That should probably be done through the thermal framework like > on omap4 & omap5? >=20 >>=20 >> For normal OPPs, using the twl regulator directly should be OK. >=20 > Maybe for the turbo OPPs as well. >=20 >> For the higher modes, maybe we could pass the callback functions >> from arch/arm/mach-omap2/voltage.c for the twl regulator so the >> voltage processor hardware can handle them directly. Or add a >> separate regulator driver operating the voltages like Nishanth >> posted patches for earlier. >=20 > So in my (limited) understanding it would suffice to set the ABB LDO > to FBB mode for OPP1G. Ok, we have to check if the ti,abb-v2 "LDO" driver=20 drivers/regulator/ti-abb-regulator.c can handle that with a DT entry similar to: = https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/omap5.dts= i#L365 Needs a little time to add to a new version of the patch set. > And make sure that the TJ does not exceed 90=C2=B0C by reducing the = cpufreq > through the thermal framework. But: the thermal sensors of the omap3 > are quite odd (they seem to jump up by 10=C2=B0 after first use). I'll leave this out for the moment for future study. BR and thanks, Nikolaus