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.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 F29D6C433DB for ; Mon, 25 Jan 2021 00:49:43 +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 9BF3B22B4B for ; Mon, 25 Jan 2021 00:49:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BF3B22B4B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aj.id.au 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:Subject:To:From:Date:References:In-Reply-To: Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sAyg++lO8e0KD2ERd2yt5eydPWgSwJLbyZ7YCuuZzl4=; b=RHSI+zsTSThJXw4MpUvfD07ls s1HATqMMydXO0vkteyIGOx1pYXsM8Dj/p+mGT/ybWQoQy8g/RLrLn9bp3LPQFM3FesXvHhUrauoa2 AZMl/yBmWKB9b78DjgBopVcbyzo0HmiI7+MaayiiCR+M5AaBhlxdyVxSUZ35XtrP1tSNIDJBXWejG 0Bq4RJcE1bBvbL+LbIAnR8KJJDWMPoEnxNrV5xlZQ/FXh84nDU2iSzXBaxm28FnuD5puzFr1KRzMA DHuebPuoyMScVAcr8R1sZkPjXRPH6Mzq7Snc2zk9J2vJHCPOHQi8psygRdSqsITcu8BBy717qoTv0 vKX3SZApw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l3q2s-00053C-M5; Mon, 25 Jan 2021 00:47:54 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l3q2o-00051f-QX for linux-arm-kernel@lists.infradead.org; Mon, 25 Jan 2021 00:47:52 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F34335C00D4; Sun, 24 Jan 2021 19:47:46 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Sun, 24 Jan 2021 19:47:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=y1nWTSF553upeE1Epom1RrsssjZa5L2 ibP59KtZo8T0=; b=Ut+P9DcY3DtzVn969+U0jXWzJI6fZA59WXlEgDuJU28e4Uf lJjp8TL2HPGfoZ1dZEp/OEFIEbxhqGu/TnuiRSTK7zpbZBWFQyQYofoKfh9obmzI /6WKAMt/fa04djYgu3ZSNitMsG9LUHlSFRzoHzJM8dXJRXspR5E8AyYgZOvX9xZd pKvtIq0x5+0esqZTlfg9CU8Kd+v0gtGqNI6KOEKOIpf2WtNcvJlC2YaxCiDElsT9 pSZNqU1Ch1m+Hr5HbB8LbDRw80rqePiHBtIIBUvcqV8tV3MO6DDiqGVDDmfXhi7c Zf4vQJl9zjwXixTmDvJL9fLN5J+axH5hj1DYcpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=y1nWTS F553upeE1Epom1RrsssjZa5L2ibP59KtZo8T0=; b=RyGecOrdRR+ctcQgEt4SCe 8lzzc2w8yX7ZaqRxKd7dVKN1EyuI+B4qVGgWsE5/0BmzLzVpEWsXK9DlnNsr+XGk JXq1CJXu2SS7Hp+6aEVBicd9rvvbFchUriCKTeJNsGv5JzZ1CI6p/Q7O+GgLD/Ef +O4NlS7lBqG08OwZFZbc09C3gH6u2rIY4oasJU45MDduLM4pRMXdfFfVnXg9wXym 2nO2e+EvLz4m4csPvEgFqLgd3xH6E2Fm+MJ2PEqDrNdtzsELtheg6TMHe2CT/y0Y wlwf89A4j79SdXxQs39pxeiBIZSfmMpGQHh4+8/ka4ew5sRPPO4UhxI3cFX8Rh6g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddvgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedftehnughr vgifucflvghffhgvrhihfdcuoegrnhgurhgvfiesrghjrdhiugdrrghuqeenucggtffrrg htthgvrhhnpeffgeffveduueeljefgfeevhfegtefguefgkeefhfekjeeivdekiedttddv ledvvdenucffohhmrghinhepkhgvrhhnvghlrdhorhhgpdhinhhfrhgruggvrggurdhorh hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghn ughrvgifsegrjhdrihgurdgruh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A76A2A0005D; Sun, 24 Jan 2021 19:47:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-78-g36b56e88ef-fm-20210120.001-g36b56e88 Mime-Version: 1.0 Message-Id: <57a20436-5d12-4f7c-b413-0cd1908acf02@www.fastmail.com> 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> <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> Date: Mon, 25 Jan 2021 11:17:24 +1030 From: "Andrew Jeffery" To: "Ryan Chen" , "Samuel Holland" , "Stephen Boyd" , "Joel Stanley" Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210124_194751_245024_9AB73B7B X-CRM114-Status: GOOD ( 32.93 ) 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 , linux-aspeed , 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 On Fri, 22 Jan 2021, at 18:45, Ryan Chen wrote: > Hello, > How about this patch progress? > It does impact a lot of machine that when BMC boot at u-boot. > SUART is work for Host. But after boot into kernel, due to the clk disabled. > The SUART is not work for Host anymore. Maybe it's worth taking Ryan's patch for now, and when the protected-clocks binding gets merged we can rip out the CLK_IS_CRITICAL flags and convert the Aspeed devicetrees to use protected-clocks instead? The only issue I see with that plan is it becomes ambiguous as to which clock each platform considers crititical/in-need-of-protection. Andrew > > Regards, > Ryan > > -----Original Message----- > > From: Samuel Holland > > Sent: Thursday, October 29, 2020 10:25 AM > > To: Stephen Boyd ; Joel Stanley > > Cc: Andrew Jeffery ; Michael Turquette > > ; Ryan Chen ; > > BMC-SW ; Linux ARM > > ; linux-aspeed > > ; linux-clk@vger.kernel.org; Linux Kernel > > Mailing List > > Subject: Re: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical > > > > 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 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel