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=-9.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 F2CE2C4363A for ; Thu, 29 Oct 2020 02:25:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5E6BE20728 for ; Thu, 29 Oct 2020 02:25:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SJevsZlT"; dkim=temperror (0-bit key) header.d=sholland.org header.i=@sholland.org header.b="kFsa6yqY"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="cdoCFbrI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E6BE20728 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sholland.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/NWP4oPrSsP07vOPJM9ThgBGRkmQh8xM/KnwIWftvMM=; b=SJevsZlTvM3AkGzKAgEdxp5JQ i0ySJost6BfbCP+BoVm08B/K5HyRd4C1684G+KnEWR6MKv5CeeoJa2DQQrauxjJJ7s9r/7TOKyMwx HsHmzfJ+9wlyUbZkJW3fI1vVBhv0hZ8f5Pq4EInx5Ytj0++Jv0SWpdgxAbqJemaXK7wuZM6Pd2MrT Nsdb6H0o/OfgLRSXT1CSCsahZ3c1OdKzvsSzHvQgNDYRJ9KBCnJdJSAnsCBzUW7yc/ZC5InlSfjdh 1KwvvSJJPdbtCXUG9DADGaeEoSySry9RO+/rTpGECv9K/6LNB1IxigELaL7hmaGLhSnYcQFjTzA9n ukKv6kdgg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXxcz-00084n-LS; Thu, 29 Oct 2020 02:25:25 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kXxcw-00083R-Jq for linux-arm-kernel@lists.infradead.org; Thu, 29 Oct 2020 02:25:23 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 37C725C0136; Wed, 28 Oct 2020 22:25:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 28 Oct 2020 22:25:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=M fF4AAKwDJHpJBHd8BnuDeW9kv0jiOpFjUocPRCzXs8=; b=kFsa6yqYhx4U/t5Zt EtuTgTF1atSaMwwxCtfVIRLqxDjxMJwjbdJ20AFO4d0IDNkxt4zQ7T4947cFyzfB PSiHqz1nmqJyFXmDepx3dlSg6635rRK9Gp9sWJZCsZh3X+DIqmFh8hVI/pDcfsiv iLnKJlTc01i3cRsrFx1pxq1P9lw3n+aINKK2Du5xjH6a2KYvosu9Wa0SuPtbG+as 7OSF6dODskAZRbudFICUvv5ZhIj2UtlyCi0EsPGI7PJmaEXfMFenVvsKmKdrvd9t 1QZu79Nca9J7RvPpvQQQd1+GFdMEkt4Pn8pNehGQQshcenY1UUat+Dt/peJxNvi/ 707Iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=MfF4AAKwDJHpJBHd8BnuDeW9kv0jiOpFjUocPRCzX s8=; b=cdoCFbrI+jKI/dO9NoJsiDorx/CLu4e/SRCDmE7OjQZejZH7zjj1Zz7MI mM1iII8Td0cnhAsyUNxM0batxG+XqLrF9BSXo6TXpLgqpOKaPH2uoDNrsgx2y2SK DuQcZKLls86zWwYmAXpDQ11nyYN0oJfWxTK8OpiEhPAUN0HsxumN1rtE3m8JwLg2 AaWiOSQzg9VUjCYf7CEt3d/tp58Qbx316g/Kxvj3Q6f1v3BLb9Jfx2wU9qQFIoR5 nE32nglF8xNLUxsEjw7uc4laLyqy98FOGdmk+EMlSTpY7IChK+ufKV9p/uDhzimF JNzE1SlleiKMKVLZVpq557NimhBmA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrledvgdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefurghmuhgv lhcujfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtf frrghtthgvrhhnpefffedvhfehhfekfeetieehfedtveduvdelieelgeettdefjefhjeek tdfftdejkeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecukfhppeejtddrudefhe drudegkedrudehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhg X-ME-Proxy: Received: from [192.168.50.169] (70-135-148-151.lightspeed.stlsmo.sbcglobal.net [70.135.148.151]) by mail.messagingengine.com (Postfix) with ESMTPA id 6239F328005E; Wed, 28 Oct 2020 22:25:15 -0400 (EDT) Subject: Re: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical To: Stephen Boyd , Joel Stanley References: <20200928070108.14040-1-ryan_chen@aspeedtech.com> <20200928070108.14040-2-ryan_chen@aspeedtech.com> <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> From: Samuel Holland Message-ID: Date: Wed, 28 Oct 2020 21:25:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201028_222522_719513_85F8E0FA X-CRM114-Status: GOOD ( 20.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: BMC-SW , Ryan Chen , linux-aspeed , Andrew Jeffery , Michael Turquette , Linux Kernel Mailing List , linux-clk@vger.kernel.org, Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Stephen, On 10/14/20 12:16 PM, Stephen Boyd wrote: > Quoting Joel Stanley (2020-10-13 22:28:00) >> On Wed, 14 Oct 2020 at 02:50, Stephen Boyd wrote: >>> >>> Quoting Ryan Chen (2020-09-28 00:01:08) >>>> In ASPEED SoC LCLK is LPC clock for all SuperIO device, UART1/UART2 are >>>> default for Host SuperIO UART device, eSPI clk for Host eSPI bus access >>>> eSPI slave channel, those clks can't be disable should keep default, >>>> otherwise will affect Host side access SuperIO and SPI slave device. >>>> >>>> Signed-off-by: Ryan Chen >>>> --- >>> >>> Is there resolution on this thread? >> >> Not yet. >> >> We have a system where the BMC (management controller) controls some >> clocks, but the peripherals that it's clocking are outside the BMC's >> control. In this case, the host processor us using some UARTs and what >> not independent of any code running on the BMC. >> >> Ryan wants to have them marked as critical so the BMC never powers them down. >> >> However, there are systems that don't use this part of the soc, so for >> those implementations they are not critical and Linux on the BMC can >> turn them off. >> >> Do you have any thoughts? Has anyone solved a similar problem already? >> > > Is this critical clocks in DT? Where we want to have different DT for > different device configurations to indicate that some clks should be > marked critical so they're never turned off and other times they aren't > so they're turned off? > > It also sounds sort of like the protected-clocks binding. Where you > don't want to touch certain clks depending on the usage configuration of > the SoC. There is a patch to make that generic that I haven't applied > because it looks wrong at first glance[1]. Maybe not registering those > clks to the framework on the configuration that Ryan has is good enough? Could you please be more specific than the patch "looks wrong"? I'm more than happy to update the patch to address your concerns, but I cannot do that unless I know what your concerns are. Regards, Samuel > [1] https://lore.kernel.org/r/20200903040015.5627-2-samuel@sholland.org _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel