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

quoted

-----Original Message-----
From: Samuel Holland <samuel@sholland.org>
Sent: Thursday, October 29, 2020 10:25 AM
To: Stephen Boyd <sboyd@kernel.org>; Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <redacted>; Michael Turquette
[off-list ref]; Ryan Chen [off-list ref];
BMC-SW [off-list ref]; Linux ARM
[off-list ref]; linux-aspeed
[off-list ref]; linux-clk at vger.kernel.org; Linux Kernel
Mailing List [off-list ref]
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:

quoted

Quoting Joel Stanley (2020-10-13 22:28:00)

quoted

On Wed, 14 Oct 2020 at 02:50, Stephen Boyd [off-list ref] wrote:

quoted

Quoting Ryan Chen (2020-09-28 00:01:08)

quoted

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.

quoted

quoted

quoted

quoted

Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---

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.

quoted

quoted

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

quoted

[1]
https://lore.kernel.org/r/20200903040015.5627-2-samuel at sholland.org

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel