All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Chen <ryan_chen@aspeedtech.com>
To: Samuel Holland <samuel@sholland.org>,
	Stephen Boyd <sboyd@kernel.org>, Joel Stanley <joel@jms.id.au>
Cc: Andrew Jeffery <andrew@aj.id.au>,
	Michael Turquette <mturquette@baylibre.com>,
	BMC-SW <BMC-SW@aspeedtech.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-aspeed <linux-aspeed@lists.ozlabs.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical
Date: Fri, 22 Jan 2021 08:15:34 +0000	[thread overview]
Message-ID: <HK0PR06MB338049BAE1D1DAE7567F620DF2A00@HK0PR06MB3380.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <adadc9ef-32ab-0a79-327c-c499c1c04093@sholland.org>

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. 

Regards,
Ryan
> -----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 <andrew@aj.id.au>; Michael Turquette
> <mturquette@baylibre.com>; Ryan Chen <ryan_chen@aspeedtech.com>;
> BMC-SW <BMC-SW@aspeedtech.com>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>; linux-aspeed
> <linux-aspeed@lists.ozlabs.org>; linux-clk@vger.kernel.org; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>
> 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 <sboyd@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@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.
> >>
> >> 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

WARNING: multiple messages have this Message-ID (diff)
From: Ryan Chen <ryan_chen@aspeedtech.com>
To: Samuel Holland <samuel@sholland.org>,
	Stephen Boyd <sboyd@kernel.org>, Joel Stanley <joel@jms.id.au>
Cc: BMC-SW <BMC-SW@aspeedtech.com>,
	linux-aspeed <linux-aspeed@lists.ozlabs.org>,
	Andrew Jeffery <andrew@aj.id.au>,
	Michael Turquette <mturquette@baylibre.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: RE: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical
Date: Fri, 22 Jan 2021 08:15:34 +0000	[thread overview]
Message-ID: <HK0PR06MB338049BAE1D1DAE7567F620DF2A00@HK0PR06MB3380.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <adadc9ef-32ab-0a79-327c-c499c1c04093@sholland.org>

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. 

Regards,
Ryan
> -----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 <andrew@aj.id.au>; Michael Turquette
> <mturquette@baylibre.com>; Ryan Chen <ryan_chen@aspeedtech.com>;
> BMC-SW <BMC-SW@aspeedtech.com>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>; linux-aspeed
> <linux-aspeed@lists.ozlabs.org>; linux-clk@vger.kernel.org; Linux Kernel
> Mailing List <linux-kernel@vger.kernel.org>
> 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 <sboyd@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@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.
> >>
> >> 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

  reply	other threads:[~2021-01-22  8:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28  7:01 [PATCH 0/1] Modify ASPEED SoC some default clks are critical Ryan Chen
2020-09-28  7:01 ` Ryan Chen
2020-09-28  7:01 ` [PATCH 1/1] clk: aspeed: modify " Ryan Chen
2020-09-28  7:01   ` Ryan Chen
2020-09-29  8:04   ` Joel Stanley
2020-09-29  8:04     ` Joel Stanley
2020-09-29  8:37     ` Ryan Chen
2020-09-29  8:37       ` Ryan Chen
2020-10-07 11:34       ` Joel Stanley
2020-10-07 11:34         ` Joel Stanley
2020-10-08  2:33         ` Ryan Chen
2020-10-08  2:33           ` Ryan Chen
2020-10-14  2:50   ` Stephen Boyd
2020-10-14  2:50     ` Stephen Boyd
2020-10-14  5:28     ` Joel Stanley
2020-10-14  5:28       ` Joel Stanley
2020-10-14  5:39       ` Ryan Chen
2020-10-14  5:39         ` Ryan Chen
2020-10-14 17:16       ` Stephen Boyd
2020-10-14 17:16         ` Stephen Boyd
2020-10-28  4:38         ` Joel Stanley
2020-10-28  4:38           ` Joel Stanley
2020-10-29  2:25         ` Samuel Holland
2020-10-29  2:25           ` Samuel Holland
2021-01-22  8:15           ` Ryan Chen [this message]
2021-01-22  8:15             ` Ryan Chen
2021-01-25  0:47             ` Andrew Jeffery
2021-01-25  0:47               ` Andrew Jeffery
2021-02-01  7:16               ` Ryan Chen
2021-02-01  7:16                 ` Ryan Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HK0PR06MB338049BAE1D1DAE7567F620DF2A00@HK0PR06MB3380.apcprd06.prod.outlook.com \
    --to=ryan_chen@aspeedtech.com \
    --cc=BMC-SW@aspeedtech.com \
    --cc=andrew@aj.id.au \
    --cc=joel@jms.id.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=samuel@sholland.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.