All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-amlogic@lists.infradead.org, carlo@caione.org
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: Re: [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b
Date: Tue, 04 Dec 2018 16:53:01 -0800	[thread overview]
Message-ID: <7htvjsbxqq.fsf@baylibre.com> (raw)
In-Reply-To: <20181129230044.21358-1-martin.blumenstingl@googlemail.com>

Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:

> This series enables CPU frequency scaling on Meson8 and Meson8b. On
> these SoCs all CPU cores are using the same clock, so all cores will
> always run at the same frequency.
>
> On Meson8b this is pretty straight-forward by taking the frequency and
> voltage table from Amlogic's 3.10 vendor kernel and converting it to
> "operating-points-v2".
>
> Meson8 (which is inherited by Meson8m2) is not so straight forward:
> The 3.10 vendor kernel contains two frequency and voltage tables with
> different voltages for the same frequency. It turns out that this is
> due to the design of a specific reference board where the output
> voltage of the regulator is limited. This has nothing to do with the
> recommended voltages of the chip so this adds the "operating-points-v2"
> which are used by all boards in the vendor kernel except the special
> case.
> The two fastest (clock rates: 1.8GHz and 1.992GHz) operating points are
> causing my Meson8m2 "M8S" (not upstream yet) board to lock up hard with
> instruction errors. I'm not sure if this is due to the poor design of
> the PCB (the LED is getting darker when I switch to 1.8GHz and soon
> after that it will crash). Thus I decided to play safe and disabled
> these two frequencies for now.
>
> Special thanks to Jianxin from Amlogic who patiently replied to all of
> my questions about the CPU clocks (without his hints I would still be
> looking at why I'm seeing random lockups when running the CPU off
> cpu_in_div3 or why the udelay is not working properly)!
>
> This is successfully tested on:
> - Meson8b: Odroid-C1 and EC-100
> - Meson8m2: MXIII-Plus and my "M8S" board (the latter is not upstream
>   yet) with frequencies up to 1.608GHz
>
> Dependencies of this series:
> - these patches are based on my other series: [0] "32-bit Meson: add
>   the ARM TWD and Global Timers"
> - when not running linux-next this requires the the clock driver
>   patches which are queued for v4.21: [1] "[GIT PULL] clk: meson:
>   updates for v4.21"
> - when not running linux-next there is a runtime dependency on the
>   meson6_timer from [2] "clocksource/meson6_timer: implement ARM
>   delay timer" because changing the CPU clock requires a small udelay
>   which only works properly when using a timer as clocksource (instead
>   of running a jiffies based delay loop where the timing changes with
>   the CPU frequency)

Thanks for the detailed description of dependencies.

Applied to v4.21/dt,

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-amlogic@lists.infradead.org, carlo@caione.org
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b
Date: Tue, 04 Dec 2018 16:53:01 -0800	[thread overview]
Message-ID: <7htvjsbxqq.fsf@baylibre.com> (raw)
In-Reply-To: <20181129230044.21358-1-martin.blumenstingl@googlemail.com>

Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:

> This series enables CPU frequency scaling on Meson8 and Meson8b. On
> these SoCs all CPU cores are using the same clock, so all cores will
> always run at the same frequency.
>
> On Meson8b this is pretty straight-forward by taking the frequency and
> voltage table from Amlogic's 3.10 vendor kernel and converting it to
> "operating-points-v2".
>
> Meson8 (which is inherited by Meson8m2) is not so straight forward:
> The 3.10 vendor kernel contains two frequency and voltage tables with
> different voltages for the same frequency. It turns out that this is
> due to the design of a specific reference board where the output
> voltage of the regulator is limited. This has nothing to do with the
> recommended voltages of the chip so this adds the "operating-points-v2"
> which are used by all boards in the vendor kernel except the special
> case.
> The two fastest (clock rates: 1.8GHz and 1.992GHz) operating points are
> causing my Meson8m2 "M8S" (not upstream yet) board to lock up hard with
> instruction errors. I'm not sure if this is due to the poor design of
> the PCB (the LED is getting darker when I switch to 1.8GHz and soon
> after that it will crash). Thus I decided to play safe and disabled
> these two frequencies for now.
>
> Special thanks to Jianxin from Amlogic who patiently replied to all of
> my questions about the CPU clocks (without his hints I would still be
> looking at why I'm seeing random lockups when running the CPU off
> cpu_in_div3 or why the udelay is not working properly)!
>
> This is successfully tested on:
> - Meson8b: Odroid-C1 and EC-100
> - Meson8m2: MXIII-Plus and my "M8S" board (the latter is not upstream
>   yet) with frequencies up to 1.608GHz
>
> Dependencies of this series:
> - these patches are based on my other series: [0] "32-bit Meson: add
>   the ARM TWD and Global Timers"
> - when not running linux-next this requires the the clock driver
>   patches which are queued for v4.21: [1] "[GIT PULL] clk: meson:
>   updates for v4.21"
> - when not running linux-next there is a runtime dependency on the
>   meson6_timer from [2] "clocksource/meson6_timer: implement ARM
>   delay timer" because changing the CPU clock requires a small udelay
>   which only works properly when using a timer as clocksource (instead
>   of running a jiffies based delay loop where the timing changes with
>   the CPU frequency)

Thanks for the detailed description of dependencies.

Applied to v4.21/dt,

Kevin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Hilman <khilman@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-amlogic@lists.infradead.org, carlo@caione.org
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b
Date: Tue, 04 Dec 2018 16:53:01 -0800	[thread overview]
Message-ID: <7htvjsbxqq.fsf@baylibre.com> (raw)
In-Reply-To: <20181129230044.21358-1-martin.blumenstingl@googlemail.com>

Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:

> This series enables CPU frequency scaling on Meson8 and Meson8b. On
> these SoCs all CPU cores are using the same clock, so all cores will
> always run at the same frequency.
>
> On Meson8b this is pretty straight-forward by taking the frequency and
> voltage table from Amlogic's 3.10 vendor kernel and converting it to
> "operating-points-v2".
>
> Meson8 (which is inherited by Meson8m2) is not so straight forward:
> The 3.10 vendor kernel contains two frequency and voltage tables with
> different voltages for the same frequency. It turns out that this is
> due to the design of a specific reference board where the output
> voltage of the regulator is limited. This has nothing to do with the
> recommended voltages of the chip so this adds the "operating-points-v2"
> which are used by all boards in the vendor kernel except the special
> case.
> The two fastest (clock rates: 1.8GHz and 1.992GHz) operating points are
> causing my Meson8m2 "M8S" (not upstream yet) board to lock up hard with
> instruction errors. I'm not sure if this is due to the poor design of
> the PCB (the LED is getting darker when I switch to 1.8GHz and soon
> after that it will crash). Thus I decided to play safe and disabled
> these two frequencies for now.
>
> Special thanks to Jianxin from Amlogic who patiently replied to all of
> my questions about the CPU clocks (without his hints I would still be
> looking at why I'm seeing random lockups when running the CPU off
> cpu_in_div3 or why the udelay is not working properly)!
>
> This is successfully tested on:
> - Meson8b: Odroid-C1 and EC-100
> - Meson8m2: MXIII-Plus and my "M8S" board (the latter is not upstream
>   yet) with frequencies up to 1.608GHz
>
> Dependencies of this series:
> - these patches are based on my other series: [0] "32-bit Meson: add
>   the ARM TWD and Global Timers"
> - when not running linux-next this requires the the clock driver
>   patches which are queued for v4.21: [1] "[GIT PULL] clk: meson:
>   updates for v4.21"
> - when not running linux-next there is a runtime dependency on the
>   meson6_timer from [2] "clocksource/meson6_timer: implement ARM
>   delay timer" because changing the CPU clock requires a small udelay
>   which only works properly when using a timer as clocksource (instead
>   of running a jiffies based delay loop where the timing changes with
>   the CPU frequency)

Thanks for the detailed description of dependencies.

Applied to v4.21/dt,

Kevin

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  parent reply	other threads:[~2018-12-05  0:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 23:00 [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b Martin Blumenstingl
2018-11-29 23:00 ` Martin Blumenstingl
2018-11-29 23:00 ` Martin Blumenstingl
2018-11-29 23:00 ` [PATCH 1/2] ARM: dts: meson: meson8: add the CPU OPP table Martin Blumenstingl
2018-11-29 23:00   ` Martin Blumenstingl
2018-11-29 23:00   ` Martin Blumenstingl
2018-11-29 23:00 ` [PATCH 2/2] ARM: dts: meson: meson8b: add the CPU OPP tables Martin Blumenstingl
2018-11-29 23:00   ` Martin Blumenstingl
2018-11-29 23:00   ` Martin Blumenstingl
2018-12-05  0:53 ` Kevin Hilman [this message]
2018-12-05  0:53   ` [PATCH 0/2] ARM: dts: enable CPU frequency scaling on Meson8/Meson8b Kevin Hilman
2018-12-05  0:53   ` Kevin Hilman

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=7htvjsbxqq.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=carlo@caione.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    /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.