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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 5C49EC43457 for ; Wed, 14 Oct 2020 17:16:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8F39221EB for ; Wed, 14 Oct 2020 17:16:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602695777; bh=GPUXWxygTTFK2yO2zrP4ocnR/PLfIqfLY8RH+LbjyTU=; h=In-Reply-To:References:Subject:From:Cc:To:Date:List-ID:From; b=jqXVdH0K6s/IybZYz7E5lGl5iMIJOzImMfWNHNT7CHjaIxeBJr3SYXPfd+3vCAu9s pYjRxX4dy3r765VoQfJU/Zpbl8sVSyrEkOTS3Wt4tLurRJjUgTK3/c5NPeoaVfcS5R WMakTCIvQla6E+qMW8QBvkRegDZUjrHgcUAz5Ekw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732035AbgJNRQP (ORCPT ); Wed, 14 Oct 2020 13:16:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:48952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727162AbgJNRQP (ORCPT ); Wed, 14 Oct 2020 13:16:15 -0400 Received: from kernel.org (unknown [104.132.1.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 94F332173E; Wed, 14 Oct 2020 17:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602695774; bh=GPUXWxygTTFK2yO2zrP4ocnR/PLfIqfLY8RH+LbjyTU=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=jI4/ayXD7kygEXy/J2VfN+TNA01XyTmvWho35XqQRwkmDmI0Z0RyH4uJT4RUfPu// Fvmno32y1rerarRfrD+M2Qd8qG7+b1xjPG7q7e7rYIMeQHtFqQI+LgiPvlE6pgFU3B aNnfPaK7GdIarcDiCUctU/0IJU7aWxDbZu5ChYsE= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20200928070108.14040-1-ryan_chen@aspeedtech.com> <20200928070108.14040-2-ryan_chen@aspeedtech.com> <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical From: Stephen Boyd Cc: Andrew Jeffery , Michael Turquette , Ryan Chen , BMC-SW , Linux ARM , linux-aspeed , linux-clk@vger.kernel.org, Linux Kernel Mailing List To: Joel Stanley Date: Wed, 14 Oct 2020 10:16:13 -0700 Message-ID: <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 a= re > > > default for Host SuperIO UART device, eSPI clk for Host eSPI bus acce= ss > > > 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? >=20 > Not yet. >=20 > 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. >=20 > Ryan wants to have them marked as critical so the BMC never powers them d= own. >=20 > 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. >=20 > Do you have any thoughts? Has anyone solved a similar problem already? >=20 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? [1] https://lore.kernel.org/r/20200903040015.5627-2-samuel@sholland.org 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 ABACDC433E7 for ; Wed, 14 Oct 2020 17:17:40 +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 1777622227 for ; Wed, 14 Oct 2020 17:17:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XV9Sl+Cc"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="jI4/ayXD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1777622227 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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:Message-ID:Date:To:From:Subject:References: In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o5NuHX4mm0r0XzpxTqZCMOug2sYrT1X7z36z+LtbGpg=; b=XV9Sl+CcZfe2flSdcG/fVqJBp ef4nHqdoVf781kIpVd/hW1wXuRQK1zg1MI1icYRPt4IO8EIIfin2Tk79alJPVIKiMUtMxdsYCF3bE DBRUtX2yjamaBHkODsN0o5iISzZjlhzBas1f/q7QumPbOJtcLK7PQN+hgibHGn5ycy40WW00pA8SA zxYsFzgVEJfcoMvorVYIzxnVAALMb2VaE2SAjf2hblEwvmoNmwIU0JfX4GwKMfRq/PTyqESAJK0JR +KXU8jMzoe8f7GnTKum2+r0djVnbfoYYHVwRVuS7NJwkd4k5njSCCwPWWD6+BQJGwyehG2rtw4xE9 kw0VGZiog==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSkNu-0005ct-CD; Wed, 14 Oct 2020 17:16:18 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kSkNr-0005cP-Hv for linux-arm-kernel@lists.infradead.org; Wed, 14 Oct 2020 17:16:16 +0000 Received: from kernel.org (unknown [104.132.1.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 94F332173E; Wed, 14 Oct 2020 17:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602695774; bh=GPUXWxygTTFK2yO2zrP4ocnR/PLfIqfLY8RH+LbjyTU=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=jI4/ayXD7kygEXy/J2VfN+TNA01XyTmvWho35XqQRwkmDmI0Z0RyH4uJT4RUfPu// Fvmno32y1rerarRfrD+M2Qd8qG7+b1xjPG7q7e7rYIMeQHtFqQI+LgiPvlE6pgFU3B aNnfPaK7GdIarcDiCUctU/0IJU7aWxDbZu5ChYsE= MIME-Version: 1.0 In-Reply-To: References: <20200928070108.14040-1-ryan_chen@aspeedtech.com> <20200928070108.14040-2-ryan_chen@aspeedtech.com> <160264382296.310579.9835482254268204873@swboyd.mtv.corp.google.com> Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical From: Stephen Boyd To: Joel Stanley Date: Wed, 14 Oct 2020 10:16:13 -0700 Message-ID: <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201014_131615_665648_7AFE1E00 X-CRM114-Status: GOOD ( 20.04 ) 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 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? [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