-----Original Message-----
From: Andrew Jeffery <redacted>
Sent: Monday, January 25, 2021 8:47 AM
To: Ryan Chen <ryan_chen@aspeedtech.com>; Samuel Holland
[off-list ref]; Stephen Boyd [off-list ref]; Joel Stanley
[off-list ref]
Cc: BMC-SW <redacted>; linux-aspeed
[off-list ref]; Michael Turquette
[off-list ref]; Linux Kernel Mailing List
[off-list ref]; linux-clk@vger.kernel.org; Linux ARM
[off-list ref]
Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical



On Fri, 22 Jan 2021, at 18:45, Ryan Chen wrote:

quoted

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.

Hello Joel,
	Will you take this patch? Or you have another approach I may modify for it. 

Regards,
Ryan

quoted

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@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

quoted

quoted

quoted

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?

quoted

quoted

quoted

quoted

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@sholland.or
g

_______________________________________________
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