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 620AAC4740C for ; Mon, 9 Sep 2019 17:03:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 29B58218DE for ; Mon, 9 Sep 2019 17:03:22 +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="SBWrOwEh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405367AbfIIRDV (ORCPT ); Mon, 9 Sep 2019 13:03:21 -0400 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.50]:35195 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727942AbfIIRDU (ORCPT ); Mon, 9 Sep 2019 13:03:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1568048598; 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=e4KiBjbBi2kS+5GZ+r+GKl60wpPTG+RMZvQ4YSIQcJQ=; b=SBWrOwEhSNJbeJCi03w1API51CFxwZ/W+/FpZhaZEJjb7pJimVZQryt6iaRJU0a1od d6L+c8E/wxDUKoRJ1VHkNLV4PGHHoU0R/frLmCdxSqWNWKXSiaVbeQkcZnBkjv72C3um fgeSW4S43HgguuOz8kiLDZsLSt3ScBUUyt7lD1dUSWDOPJ1paooiJUNoMFKioD97KlpN RP7Teb73OjDj2AMDGx37yDzVc19mq6yL2SPwIQtEASHwLtnXTodosDa9YPmmF9uAMcwP Vi4AEY7wak1fr34cBQya2xY4RciWfQFJ25hY4jWriSPduQf8c094Zo6ieqHFEP3PYZJR RAsw== 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 u036f9v89H36xyC (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 19:03:06 +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 19:03:06 +0200 Cc: Tony Lindgren , =?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: Adam Ford 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:38 schrieb Adam Ford : >=20 > On Mon, Sep 9, 2019 at 11:32 AM Tony Lindgren = wrote: >>=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 > I thought there was a thermal sensor? Yes. >=20 > cpu_thermal: cpu_thermal { > polling-delay-passive =3D <250>; /* milliseconds */ > polling-delay =3D <1000>; /* milliseconds */ > coefficients =3D <0 20000>; >=20 > /* sensor ID */ > thermal-sensors =3D <&bandgap 0>; > }; >=20 > Can this driver somehow notify the cpufreq that we've hit some limit? > I know it's not as accurate as one would like, but even for non-1GHz > versions, having it downclock would be a good thing when running at > extreme temps. Indeed it is not really reliable. For me it jumps up by 10=C2=B0 between = first reading within the next second (and seems to stay at this offset after = first use). But yes, I think it should be possible to use it similar to = omap5-core-thermal.dtsi Maybe we have to add "trips" and "core_crit". This must obviously be = linked to the cpufreq system. Or is it done automatically? BR, Nikolaus