[PATCH 1/1] clk: aspeed: modify some default clks are critical

Ryan Chen ryan_chen at aspeedtech.com
Wed Oct 14 01:39:08 EDT 2020


> -----Original Message-----
> From: Joel Stanley <joel at jms.id.au>
> Sent: Wednesday, October 14, 2020 1:28 PM
> To: Stephen Boyd <sboyd at kernel.org>
> Cc: Andrew Jeffery <andrew at aj.id.au>; Michael Turquette
> <mturquette at baylibre.com>; Ryan Chen <ryan_chen at aspeedtech.com>;
> BMC-SW <BMC-SW at aspeedtech.com>; Linux ARM
> <linux-arm-kernel at lists.infradead.org>; linux-aspeed
> <linux-aspeed at lists.ozlabs.org>; linux-clk at vger.kernel.org; Linux Kernel
> Mailing List <linux-kernel at vger.kernel.org>
> Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical
> 
> On Wed, 14 Oct 2020 at 02:50, Stephen Boyd <sboyd at kernel.org> 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 <ryan_chen at 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.
> 
> 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.
> 
Take an example, conflict thought about ASPEED_CLK_GATE_BCLK is CLK_IS_CRITICAL in clk-ast2600.c
In my opinion, the driver should keep the SoC default clk setting. It is original chip feature.  

> Do you have any thoughts? Has anyone solved a similar problem already?
> 


More information about the linux-arm-kernel mailing list