From: Joel Stanley <joel@jms.id.au> To: Stephen Boyd <sboyd@kernel.org> 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: [PATCH 1/1] clk: aspeed: modify some default clks are critical Date: Wed, 28 Oct 2020 04:38:10 +0000 [thread overview] Message-ID: <CACPK8XeGRq2XeJAjdQ=pT1oKk7-wk1==4Byfc50_6+-UijU12w@mail.gmail.com> (raw) In-Reply-To: <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> Thanks for the response Stephen. Sorry it's taken me a while to get back to you. On Wed, 14 Oct 2020 at 17:16, Stephen Boyd <sboyd@kernel.org> 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? Spot on. > 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]. That binding is exactly what I had in mind. I wasn't aware of it. The drawbacks outlined in the commit message do sound concerning. I take it we could avoid those drawbacks by having a driver-specific implementation of protected-clocks, like qcom does? > Maybe not registering those > clks to the framework on the configuration that Ryan has is good enough? I didn't quite follow here. Did you mean with protected-clocks, or using a different mechanism? Cheers, Joel > > [1] https://lore.kernel.org/r/20200903040015.5627-2-samuel@sholland.org
WARNING: multiple messages have this Message-ID (diff)
From: Joel Stanley <joel@jms.id.au> To: Stephen Boyd <sboyd@kernel.org> Cc: BMC-SW <bmc-sw@aspeedtech.com>, Ryan Chen <ryan_chen@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 ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical Date: Wed, 28 Oct 2020 04:38:10 +0000 [thread overview] Message-ID: <CACPK8XeGRq2XeJAjdQ=pT1oKk7-wk1==4Byfc50_6+-UijU12w@mail.gmail.com> (raw) In-Reply-To: <160269577311.884498.8429245140509326318@swboyd.mtv.corp.google.com> Thanks for the response Stephen. Sorry it's taken me a while to get back to you. On Wed, 14 Oct 2020 at 17:16, Stephen Boyd <sboyd@kernel.org> 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? Spot on. > 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]. That binding is exactly what I had in mind. I wasn't aware of it. The drawbacks outlined in the commit message do sound concerning. I take it we could avoid those drawbacks by having a driver-specific implementation of protected-clocks, like qcom does? > Maybe not registering those > clks to the framework on the configuration that Ryan has is good enough? I didn't quite follow here. Did you mean with protected-clocks, or using a different mechanism? Cheers, Joel > > [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
next prev parent reply other threads:[~2020-10-28 23: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 [this message] 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 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='CACPK8XeGRq2XeJAjdQ=pT1oKk7-wk1==4Byfc50_6+-UijU12w@mail.gmail.com' \ --to=joel@jms.id.au \ --cc=andrew@aj.id.au \ --cc=bmc-sw@aspeedtech.com \ --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=ryan_chen@aspeedtech.com \ --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: linkBe 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.