From: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, sboyd@kernel.org
Cc: linux-kernel@vger.kernel.org, mturquette@baylibre.com,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
narmstrong@baylibre.com
Subject: Re: [PATCH v2 0/2] clk: Meson8/8b/8m2: fix the mali clock flags
Date: Tue, 07 Jan 2020 12:03:15 +0100 [thread overview]
Message-ID: <1j36crsf4c.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com>
On Thu 26 Dec 2019 at 20:12, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> While playing with devfreq support for the lima driver I experienced
> sporadic (random) system lockups. It turned out that this was in
> certain cases when changing the mali clock.
>
> The Amlogic vendor GPU platform driver (which is responsible for
> changing the clock frequency) uses the following pattern when updating
> the mali clock rate:
> - at initialization: initialize the two mali_0 and mali_1 clock trees
> with a default setting and enable both clocks
> - when changing the clock frequency:
> -- set HHI_MALI_CLK_CNTL[31] to temporarily use the mali_1 clock output
> -- update the mali_0 clock tree (set the mux, divider, etc.)
> -- clear HHI_MALI_CLK_CNTL[31] to temporarily use the mali_0 clock
> output again
>
> With the common clock framework we can even do better:
> by setting CLK_SET_RATE_PARENT for the mali_0 and mali_1 output gates
> we can force the common clock framework to update the "inactive" clock
> and then switch to it's output.
>
> I only tested this patch for a limited time only (approx. 2 hours).
> So far I couldn't reproduce the sporadic system lockups with it.
> However, broader testing would be great so I would like this to be
> applied for -next.
>
> Changes since v1 at [0]:
> - extend the existing comment in patch #1 to describe how the glitch-
> free mux works with the CCF
> - slightly updated the patch description of patch #1 to clarify that
> the "mali_0" or "mali_1" trees must not be changed while running
> - add patch #2 to update the clk_set_rate() kerneldoc because we agreed
> that clk_set_rate() should do a root-to-leaf update (it does already,
> it's just not documented)
>
>
> [0] https://patchwork.kernel.org/cover/11293177/
>
>
> Martin Blumenstingl (2):
> clk: meson: meson8b: make the CCF use the glitch-free "mali" mux
> clk: clarify that clk_set_rate() does updates from top to bottom
>
Applied with Stephen's Ack
> drivers/clk/meson/meson8b.c | 11 +++++++----
> include/linux/clk.h | 3 +++
> 2 files changed, 10 insertions(+), 4 deletions(-)
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, sboyd@kernel.org
Cc: narmstrong@baylibre.com, mturquette@baylibre.com,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] clk: Meson8/8b/8m2: fix the mali clock flags
Date: Tue, 07 Jan 2020 12:03:15 +0100 [thread overview]
Message-ID: <1j36crsf4c.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com>
On Thu 26 Dec 2019 at 20:12, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> While playing with devfreq support for the lima driver I experienced
> sporadic (random) system lockups. It turned out that this was in
> certain cases when changing the mali clock.
>
> The Amlogic vendor GPU platform driver (which is responsible for
> changing the clock frequency) uses the following pattern when updating
> the mali clock rate:
> - at initialization: initialize the two mali_0 and mali_1 clock trees
> with a default setting and enable both clocks
> - when changing the clock frequency:
> -- set HHI_MALI_CLK_CNTL[31] to temporarily use the mali_1 clock output
> -- update the mali_0 clock tree (set the mux, divider, etc.)
> -- clear HHI_MALI_CLK_CNTL[31] to temporarily use the mali_0 clock
> output again
>
> With the common clock framework we can even do better:
> by setting CLK_SET_RATE_PARENT for the mali_0 and mali_1 output gates
> we can force the common clock framework to update the "inactive" clock
> and then switch to it's output.
>
> I only tested this patch for a limited time only (approx. 2 hours).
> So far I couldn't reproduce the sporadic system lockups with it.
> However, broader testing would be great so I would like this to be
> applied for -next.
>
> Changes since v1 at [0]:
> - extend the existing comment in patch #1 to describe how the glitch-
> free mux works with the CCF
> - slightly updated the patch description of patch #1 to clarify that
> the "mali_0" or "mali_1" trees must not be changed while running
> - add patch #2 to update the clk_set_rate() kerneldoc because we agreed
> that clk_set_rate() should do a root-to-leaf update (it does already,
> it's just not documented)
>
>
> [0] https://patchwork.kernel.org/cover/11293177/
>
>
> Martin Blumenstingl (2):
> clk: meson: meson8b: make the CCF use the glitch-free "mali" mux
> clk: clarify that clk_set_rate() does updates from top to bottom
>
Applied with Stephen's Ack
> drivers/clk/meson/meson8b.c | 11 +++++++----
> include/linux/clk.h | 3 +++
> 2 files changed, 10 insertions(+), 4 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, sboyd@kernel.org
Cc: linux-kernel@vger.kernel.org, mturquette@baylibre.com,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
narmstrong@baylibre.com
Subject: Re: [PATCH v2 0/2] clk: Meson8/8b/8m2: fix the mali clock flags
Date: Tue, 07 Jan 2020 12:03:15 +0100 [thread overview]
Message-ID: <1j36crsf4c.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com>
On Thu 26 Dec 2019 at 20:12, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> While playing with devfreq support for the lima driver I experienced
> sporadic (random) system lockups. It turned out that this was in
> certain cases when changing the mali clock.
>
> The Amlogic vendor GPU platform driver (which is responsible for
> changing the clock frequency) uses the following pattern when updating
> the mali clock rate:
> - at initialization: initialize the two mali_0 and mali_1 clock trees
> with a default setting and enable both clocks
> - when changing the clock frequency:
> -- set HHI_MALI_CLK_CNTL[31] to temporarily use the mali_1 clock output
> -- update the mali_0 clock tree (set the mux, divider, etc.)
> -- clear HHI_MALI_CLK_CNTL[31] to temporarily use the mali_0 clock
> output again
>
> With the common clock framework we can even do better:
> by setting CLK_SET_RATE_PARENT for the mali_0 and mali_1 output gates
> we can force the common clock framework to update the "inactive" clock
> and then switch to it's output.
>
> I only tested this patch for a limited time only (approx. 2 hours).
> So far I couldn't reproduce the sporadic system lockups with it.
> However, broader testing would be great so I would like this to be
> applied for -next.
>
> Changes since v1 at [0]:
> - extend the existing comment in patch #1 to describe how the glitch-
> free mux works with the CCF
> - slightly updated the patch description of patch #1 to clarify that
> the "mali_0" or "mali_1" trees must not be changed while running
> - add patch #2 to update the clk_set_rate() kerneldoc because we agreed
> that clk_set_rate() should do a root-to-leaf update (it does already,
> it's just not documented)
>
>
> [0] https://patchwork.kernel.org/cover/11293177/
>
>
> Martin Blumenstingl (2):
> clk: meson: meson8b: make the CCF use the glitch-free "mali" mux
> clk: clarify that clk_set_rate() does updates from top to bottom
>
Applied with Stephen's Ack
> drivers/clk/meson/meson8b.c | 11 +++++++----
> include/linux/clk.h | 3 +++
> 2 files changed, 10 insertions(+), 4 deletions(-)
_______________________________________________
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-01-07 11:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-26 19:12 [PATCH v2 0/2] clk: Meson8/8b/8m2: fix the mali clock flags Martin Blumenstingl
2019-12-26 19:12 ` Martin Blumenstingl
2019-12-26 19:12 ` Martin Blumenstingl
2019-12-26 19:12 ` [PATCH v2 1/2] clk: meson: meson8b: make the CCF use the glitch-free "mali" mux Martin Blumenstingl
2019-12-26 19:12 ` Martin Blumenstingl
2019-12-26 19:12 ` Martin Blumenstingl
2019-12-26 19:12 ` [PATCH v2 2/2] clk: clarify that clk_set_rate() does updates from top to bottom Martin Blumenstingl
2019-12-26 19:12 ` Martin Blumenstingl
2019-12-26 19:12 ` Martin Blumenstingl
2020-01-06 3:03 ` Stephen Boyd
2020-01-06 3:03 ` Stephen Boyd
2020-01-06 3:03 ` Stephen Boyd
2020-01-07 11:03 ` Jerome Brunet [this message]
2020-01-07 11:03 ` [PATCH v2 0/2] clk: Meson8/8b/8m2: fix the mali clock flags Jerome Brunet
2020-01-07 11:03 ` Jerome Brunet
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=1j36crsf4c.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mturquette@baylibre.com \
--cc=narmstrong@baylibre.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: 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.