From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: "Dr. Philipp Tomsich"
<philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Cc: Klaus Goger
<klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org
Subject: Re: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
Date: Wed, 28 Jun 2017 12:49:10 +0200 [thread overview]
Message-ID: <3683842.NarJoYnXid@phil> (raw)
In-Reply-To: <3F2C0996-F298-4628-BCF3-DE721F3B818D-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Am Mittwoch, 28. Juni 2017, 12:40:01 CEST schrieb Dr. Philipp Tomsich:
>
> > On 28 Jun 2017, at 12:26, Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> >
> > Hi Klaus,
> >
> > [added Kever from Rockchip concerning the cluster1-opps below]
> >
> >
> > Am Montag, 26. Juni 2017, 21:18:54 CEST schrieb Klaus Goger:
> >> The RK3399-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
> >> connector) system-on-module from Theobroma Systems, featuring the
> >> Rockchip RK3399.
> >>
> >> It provides the following feature set:
> >> * up to 4GB DDR3
> >> * on-module SPI-NOR flash
> >> * on-module eMMC (with 8-bit 1.8V interface)
> >> * SD card (on a baseboad) via edge connector
> >> * Gigabit Ethernet with on-module Micrel KSZ9031 GbE PHY
> >> * HDMI/eDP/2x MIPI-DSI
> >> * 2x MIPI-CSI
> >> * USB
> >> - 1x USB 3.0 dual-role (direct connection)
> >> - 2x USB 3.0 host + 1x USB 2.0 (on-module USB 3.0 hub)
> >> * on-module STM32 Cortex-M0 companion controller, implementing:
> >> - low-power RTC functionality (ISL1208 emulation)
> >> - fan controller (AMC6821 emulation)
> >> - USB<->CAN bridge controller
> >>
> >> Signed-off-by: Klaus Goger <klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
> >>
> >> ---
> >
> > [...]
> >
> >> + leds {
> >> + compatible = "gpio-leds";
> >> + pinctrl-names = "default";
> >> +
> >> + module_led {
> >
> > phandles use underscores, node names are supposed to use dashes "-"
> >
> >> + label = "module_led";
> >> + gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
> >> + linux,default-trigger = "heartbeat";
> >> + panic-indicator;
> >> + };
> >> +
> >> + sd_card_led {
> >> + label = "sd_card_led";
> >> + gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;
> >> + linux,default-trigger = "mmc0";
> >> + };
> >> + };
> >> +
> >> + cluster1_opp: opp-table1 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp00 {
> >> + opp-hz = /bits/ 64 <408000000>;
> >> + opp-microvolt = <800000>;
> >> + clock-latency-ns = <40000>;
> >> + };
> >> + opp01 {
> >> + opp-hz = /bits/ 64 <600000000>;
> >> + opp-microvolt = <800000>;
> >> + };
> >> + opp02 {
> >> + opp-hz = /bits/ 64 <816000000>;
> >> + opp-microvolt = <830000>;
> >
> > this is 5mV higher than the "official" OPPs used by Rockchip, so
> > I'd like to know its background :-) . Especially as I really would like
> > to keep the number of per-board OPPs minimal.
>
> The on-board regulators differ and can’t hit the voltages specified
> in the original OPP table… this is the next closest value we can
> set and is at least what Rockchip uses in the ref-design.
>
> > So does this make the board run more stable or something else?
> > And might this be applicable for all "standard" rk3399 boards?
> > Especially as other OPPs in your list use the regular voltages.
>
> It avoids ugly issues with OPPs being deactivated due to the the
> exact voltage used in the “official” OPPs not being supported by
> our regulator.
>
> We decided against reusing the original OPP table and modifying it
> (to use ranges) as that was likely to cause even more harm in the
> long term.
ok, thanks for that explanation, which also satisfies my reservations :-) .
When fixing the other things, please also add a comment above opp-table
with the above explanation, so future changers don't need to remember
this mail thread :-) .
Also, you might want to add something like
/delete-node/ opp-table1;
before defining your new opp table to prevent the subnode changes
from interfering with your new table.
> >> + opp-suspend;
> >> + };
> >> + opp03 {
> >> + opp-hz = /bits/ 64 <1008000000>;
> >> + opp-microvolt = <880000>;
> >
> > same as above
> >
> >> + };
> >> + opp04 {
> >> + opp-hz = /bits/ 64 <1200000000>;
> >> + opp-microvolt = <950000>;
> >> + };
> >> + opp05 {
> >> + opp-hz = /bits/ 64 <1416000000>;
> >> + opp-microvolt = <1030000>;
> >
> > same as above
> >
> >> + };
> >> + opp06 {
> >> + opp-hz = /bits/ 64 <1608000000>;
> >> + opp-microvolt = <1100000>;
> >> + };
> >> + opp07 {
> >> + opp-hz = /bits/ 64 <1800000000>;
> >> + opp-microvolt = <1200000>;
> >> + };
> >> + opp08 {
> >> + opp-hz = /bits/ 64 <1992000000>;
> >> + opp-microvolt = <1230000>;
> >> + turbo-mode;
> >
> > Is this part of the soc-spec or more like wishful thinking? :-)
> > Again with the question in mind if this applies to all rk3399.
>
> Tested in our lab on a decent population of boards using various
> forms of stress-testing (incl. a 6-way and 8-way SPEC).
>
> This one is marked ‘turbo-mode’ as we do recommend to only
> enable it if a (Qseven-style) heat-sink is mounted.
ok then.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
Date: Wed, 28 Jun 2017 12:49:10 +0200 [thread overview]
Message-ID: <3683842.NarJoYnXid@phil> (raw)
In-Reply-To: <3F2C0996-F298-4628-BCF3-DE721F3B818D@theobroma-systems.com>
Am Mittwoch, 28. Juni 2017, 12:40:01 CEST schrieb Dr. Philipp Tomsich:
>
> > On 28 Jun 2017, at 12:26, Heiko St?bner <heiko@sntech.de> wrote:
> >
> > Hi Klaus,
> >
> > [added Kever from Rockchip concerning the cluster1-opps below]
> >
> >
> > Am Montag, 26. Juni 2017, 21:18:54 CEST schrieb Klaus Goger:
> >> The RK3399-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
> >> connector) system-on-module from Theobroma Systems, featuring the
> >> Rockchip RK3399.
> >>
> >> It provides the following feature set:
> >> * up to 4GB DDR3
> >> * on-module SPI-NOR flash
> >> * on-module eMMC (with 8-bit 1.8V interface)
> >> * SD card (on a baseboad) via edge connector
> >> * Gigabit Ethernet with on-module Micrel KSZ9031 GbE PHY
> >> * HDMI/eDP/2x MIPI-DSI
> >> * 2x MIPI-CSI
> >> * USB
> >> - 1x USB 3.0 dual-role (direct connection)
> >> - 2x USB 3.0 host + 1x USB 2.0 (on-module USB 3.0 hub)
> >> * on-module STM32 Cortex-M0 companion controller, implementing:
> >> - low-power RTC functionality (ISL1208 emulation)
> >> - fan controller (AMC6821 emulation)
> >> - USB<->CAN bridge controller
> >>
> >> Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
> >>
> >> ---
> >
> > [...]
> >
> >> + leds {
> >> + compatible = "gpio-leds";
> >> + pinctrl-names = "default";
> >> +
> >> + module_led {
> >
> > phandles use underscores, node names are supposed to use dashes "-"
> >
> >> + label = "module_led";
> >> + gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
> >> + linux,default-trigger = "heartbeat";
> >> + panic-indicator;
> >> + };
> >> +
> >> + sd_card_led {
> >> + label = "sd_card_led";
> >> + gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;
> >> + linux,default-trigger = "mmc0";
> >> + };
> >> + };
> >> +
> >> + cluster1_opp: opp-table1 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp00 {
> >> + opp-hz = /bits/ 64 <408000000>;
> >> + opp-microvolt = <800000>;
> >> + clock-latency-ns = <40000>;
> >> + };
> >> + opp01 {
> >> + opp-hz = /bits/ 64 <600000000>;
> >> + opp-microvolt = <800000>;
> >> + };
> >> + opp02 {
> >> + opp-hz = /bits/ 64 <816000000>;
> >> + opp-microvolt = <830000>;
> >
> > this is 5mV higher than the "official" OPPs used by Rockchip, so
> > I'd like to know its background :-) . Especially as I really would like
> > to keep the number of per-board OPPs minimal.
>
> The on-board regulators differ and can?t hit the voltages specified
> in the original OPP table? this is the next closest value we can
> set and is at least what Rockchip uses in the ref-design.
>
> > So does this make the board run more stable or something else?
> > And might this be applicable for all "standard" rk3399 boards?
> > Especially as other OPPs in your list use the regular voltages.
>
> It avoids ugly issues with OPPs being deactivated due to the the
> exact voltage used in the ?official? OPPs not being supported by
> our regulator.
>
> We decided against reusing the original OPP table and modifying it
> (to use ranges) as that was likely to cause even more harm in the
> long term.
ok, thanks for that explanation, which also satisfies my reservations :-) .
When fixing the other things, please also add a comment above opp-table
with the above explanation, so future changers don't need to remember
this mail thread :-) .
Also, you might want to add something like
/delete-node/ opp-table1;
before defining your new opp table to prevent the subnode changes
from interfering with your new table.
> >> + opp-suspend;
> >> + };
> >> + opp03 {
> >> + opp-hz = /bits/ 64 <1008000000>;
> >> + opp-microvolt = <880000>;
> >
> > same as above
> >
> >> + };
> >> + opp04 {
> >> + opp-hz = /bits/ 64 <1200000000>;
> >> + opp-microvolt = <950000>;
> >> + };
> >> + opp05 {
> >> + opp-hz = /bits/ 64 <1416000000>;
> >> + opp-microvolt = <1030000>;
> >
> > same as above
> >
> >> + };
> >> + opp06 {
> >> + opp-hz = /bits/ 64 <1608000000>;
> >> + opp-microvolt = <1100000>;
> >> + };
> >> + opp07 {
> >> + opp-hz = /bits/ 64 <1800000000>;
> >> + opp-microvolt = <1200000>;
> >> + };
> >> + opp08 {
> >> + opp-hz = /bits/ 64 <1992000000>;
> >> + opp-microvolt = <1230000>;
> >> + turbo-mode;
> >
> > Is this part of the soc-spec or more like wishful thinking? :-)
> > Again with the question in mind if this applies to all rk3399.
>
> Tested in our lab on a decent population of boards using various
> forms of stress-testing (incl. a 6-way and 8-way SPEC).
>
> This one is marked ?turbo-mode? as we do recommend to only
> enable it if a (Qseven-style) heat-sink is mounted.
ok then.
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com>
Cc: Klaus Goger <klaus.goger@theobroma-systems.com>,
devicetree@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-rockchip@lists.infradead.org,
Rob Herring <robh+dt@kernel.org>,
Will Deacon <will.deacon@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org, kever.yang@rock-chips.com
Subject: Re: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
Date: Wed, 28 Jun 2017 12:49:10 +0200 [thread overview]
Message-ID: <3683842.NarJoYnXid@phil> (raw)
In-Reply-To: <3F2C0996-F298-4628-BCF3-DE721F3B818D@theobroma-systems.com>
Am Mittwoch, 28. Juni 2017, 12:40:01 CEST schrieb Dr. Philipp Tomsich:
>
> > On 28 Jun 2017, at 12:26, Heiko Stübner <heiko@sntech.de> wrote:
> >
> > Hi Klaus,
> >
> > [added Kever from Rockchip concerning the cluster1-opps below]
> >
> >
> > Am Montag, 26. Juni 2017, 21:18:54 CEST schrieb Klaus Goger:
> >> The RK3399-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
> >> connector) system-on-module from Theobroma Systems, featuring the
> >> Rockchip RK3399.
> >>
> >> It provides the following feature set:
> >> * up to 4GB DDR3
> >> * on-module SPI-NOR flash
> >> * on-module eMMC (with 8-bit 1.8V interface)
> >> * SD card (on a baseboad) via edge connector
> >> * Gigabit Ethernet with on-module Micrel KSZ9031 GbE PHY
> >> * HDMI/eDP/2x MIPI-DSI
> >> * 2x MIPI-CSI
> >> * USB
> >> - 1x USB 3.0 dual-role (direct connection)
> >> - 2x USB 3.0 host + 1x USB 2.0 (on-module USB 3.0 hub)
> >> * on-module STM32 Cortex-M0 companion controller, implementing:
> >> - low-power RTC functionality (ISL1208 emulation)
> >> - fan controller (AMC6821 emulation)
> >> - USB<->CAN bridge controller
> >>
> >> Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
> >>
> >> ---
> >
> > [...]
> >
> >> + leds {
> >> + compatible = "gpio-leds";
> >> + pinctrl-names = "default";
> >> +
> >> + module_led {
> >
> > phandles use underscores, node names are supposed to use dashes "-"
> >
> >> + label = "module_led";
> >> + gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
> >> + linux,default-trigger = "heartbeat";
> >> + panic-indicator;
> >> + };
> >> +
> >> + sd_card_led {
> >> + label = "sd_card_led";
> >> + gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;
> >> + linux,default-trigger = "mmc0";
> >> + };
> >> + };
> >> +
> >> + cluster1_opp: opp-table1 {
> >> + compatible = "operating-points-v2";
> >> + opp-shared;
> >> +
> >> + opp00 {
> >> + opp-hz = /bits/ 64 <408000000>;
> >> + opp-microvolt = <800000>;
> >> + clock-latency-ns = <40000>;
> >> + };
> >> + opp01 {
> >> + opp-hz = /bits/ 64 <600000000>;
> >> + opp-microvolt = <800000>;
> >> + };
> >> + opp02 {
> >> + opp-hz = /bits/ 64 <816000000>;
> >> + opp-microvolt = <830000>;
> >
> > this is 5mV higher than the "official" OPPs used by Rockchip, so
> > I'd like to know its background :-) . Especially as I really would like
> > to keep the number of per-board OPPs minimal.
>
> The on-board regulators differ and can’t hit the voltages specified
> in the original OPP table… this is the next closest value we can
> set and is at least what Rockchip uses in the ref-design.
>
> > So does this make the board run more stable or something else?
> > And might this be applicable for all "standard" rk3399 boards?
> > Especially as other OPPs in your list use the regular voltages.
>
> It avoids ugly issues with OPPs being deactivated due to the the
> exact voltage used in the “official” OPPs not being supported by
> our regulator.
>
> We decided against reusing the original OPP table and modifying it
> (to use ranges) as that was likely to cause even more harm in the
> long term.
ok, thanks for that explanation, which also satisfies my reservations :-) .
When fixing the other things, please also add a comment above opp-table
with the above explanation, so future changers don't need to remember
this mail thread :-) .
Also, you might want to add something like
/delete-node/ opp-table1;
before defining your new opp table to prevent the subnode changes
from interfering with your new table.
> >> + opp-suspend;
> >> + };
> >> + opp03 {
> >> + opp-hz = /bits/ 64 <1008000000>;
> >> + opp-microvolt = <880000>;
> >
> > same as above
> >
> >> + };
> >> + opp04 {
> >> + opp-hz = /bits/ 64 <1200000000>;
> >> + opp-microvolt = <950000>;
> >> + };
> >> + opp05 {
> >> + opp-hz = /bits/ 64 <1416000000>;
> >> + opp-microvolt = <1030000>;
> >
> > same as above
> >
> >> + };
> >> + opp06 {
> >> + opp-hz = /bits/ 64 <1608000000>;
> >> + opp-microvolt = <1100000>;
> >> + };
> >> + opp07 {
> >> + opp-hz = /bits/ 64 <1800000000>;
> >> + opp-microvolt = <1200000>;
> >> + };
> >> + opp08 {
> >> + opp-hz = /bits/ 64 <1992000000>;
> >> + opp-microvolt = <1230000>;
> >> + turbo-mode;
> >
> > Is this part of the soc-spec or more like wishful thinking? :-)
> > Again with the question in mind if this applies to all rk3399.
>
> Tested in our lab on a decent population of boards using various
> forms of stress-testing (incl. a 6-way and 8-way SPEC).
>
> This one is marked ‘turbo-mode’ as we do recommend to only
> enable it if a (Qseven-style) heat-sink is mounted.
ok then.
Heiko
next prev parent reply other threads:[~2017-06-28 10:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170626191854.58253-1-klaus.goger@theobroma-systems.com>
[not found] ` <20170626191854.58253-5-klaus.goger@theobroma-systems.com>
[not found] ` <20170626191854.58253-5-klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
2017-06-28 10:26 ` [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM Heiko Stübner
2017-06-28 10:26 ` Heiko Stübner
2017-06-28 10:26 ` Heiko Stübner
2017-06-28 10:40 ` Dr. Philipp Tomsich
2017-06-28 10:40 ` Dr. Philipp Tomsich
2017-06-28 10:40 ` Dr. Philipp Tomsich
[not found] ` <3F2C0996-F298-4628-BCF3-DE721F3B818D-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
2017-06-28 10:49 ` Heiko Stuebner [this message]
2017-06-28 10:49 ` Heiko Stuebner
2017-06-28 10:49 ` Heiko Stuebner
2017-06-28 12:41 ` Shawn Lin
2017-06-28 12:41 ` Shawn Lin
2017-06-28 12:41 ` Shawn Lin
[not found] ` <db92a83b-a80b-6c9f-76dc-646d9155bc20-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-06-28 14:01 ` Klaus Goger
2017-06-28 14:01 ` Klaus Goger
2017-06-28 14:01 ` Klaus Goger
[not found] ` <8378C275-0F65-4B91-A9B8-23E78799F7E5-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
2017-06-29 0:14 ` Shawn Lin
2017-06-29 0:14 ` Shawn Lin
2017-06-29 0:14 ` Shawn Lin
2017-06-30 22:13 ` Heiko Stuebner
2017-06-30 22:13 ` Heiko Stuebner
2017-06-30 22:13 ` Heiko Stuebner
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=3683842.NarJoYnXid@phil \
--to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=klaus.goger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.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.