ARM: dts: rockchip: make sure edp_24m is associated to xin24m on veyron
Heiko Stübner
maintainerPATCH 1/3 ARM: dts: rockchip: make sure edp_24m is associated to xin24m on veyron
The edp-24m clock has two possible sources: the 24MHz oscillator as well as an external 27MHz input. The power-on-default is the 27MHz clock which is not supplied on all Rockchip boards. While on all current boards and also all Veyron Chromebooks the bootloader seems to adapt the muxing to the internal source, this doesn't seem to be the case on headless veyron devices like brain and mickey making the edp-24m clock an orphan. On the hardware side the 27m input also is not connected at all.
With the upcoming deferral of orphan-clocks this results in the power- domain code deferring, as it cannot request the needed clock and if the synchronous reset is sucessfullat all in this case is also unknown.
So fix that by making sure, the edp-24m clock is muxed to the internal 24MHz oscillator at all times.
---
It seems I had some issues sending, sorry about the double-mails.
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/rk3288-veyron.dtsi +5 -0
@@ -340,6 +340,11 @@ i2c-scl-rising-time-ns = <1000>; }; +&power { + assigned-clocks = <&cru SCLK_EDP_24M>; + assigned-clock-parents = <&xin24m>; +}; + &pwm1 { status = "okay"; };
Signature · 1 line
2.6.1
PATCH 2/3 ARM: dts: rockchip: add veyron-brain board
Similar to pinky, brain is a development model and probably also nearing extinction. But to keep pinky from being lonely I'll keep the two brain boards around as well, especially as they as well have easily accessible dut-connectors.
---
would cool to get an Ack from ChromeOS-people concerning the license change to GPL2/X11 - as with the dts before
Documentation/devicetree/bindings/arm/rockchip.txt | 5 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-brain.dts | 139 +++++++++++++++++++++ 3 files changed, 145 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-veyron-brain.dts
Documentation/devicetree/bindings/arm/rockchip.txt +5 -0
@@ -35,6 +35,11 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "netxeon,r89", "rockchip,rk3288"; +- Google Brain (dev-board): + Required root node properties: + - compatible = "google,veyron-brain-rev0", "google,veyron-brain", + "google,veyron", "rockchip,rk3288"; + - Google Jaq (Haier Chromebook 11 and more): Required root node properties: - compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
arch/arm/boot/dts/Makefile +1 -0
@@ -524,6 +524,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-popmetal.dtb \ rk3288-r89.dtb \ rk3288-rock2-square.dtb \ + rk3288-veyron-brain.dtb \ rk3288-veyron-jaq.dtb \ rk3288-veyron-jerry.dtb \ rk3288-veyron-minnie.dtb \
arch/arm/boot/dts/rk3288-veyron-brain.dts new file +139 -0
139 lines not on this page · raw message
Signature · 1 line
2.6.1
PATCH 2/3 ARM: dts: rockchip: add veyron-brain board
Quoted 9 lines · Heiko St?bner
Similar to pinky, brain is a development model and probably also nearing extinction. But to keep pinky from being lonely I'll keep the two brain boards around as well, especially as they as well have easily accessible dut-connectors.
Signed-off-by Heiko Stuebner <[email protected]>---
would cool to get an Ack from ChromeOS-people concerning the license change to GPL2/X11 - as with the dts before
For the license changes:
Not tested or reviewed otherwise.
Quoted 5 lines
Documentation/devicetree/bindings/arm/rockchip.txt | 5 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-brain.dts | 139 +++++++++++++++++++++ 3 files changed, 145 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-veyron-brain.dts
...
Brian
PATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
In reply to Heiko StübnerFrom: Chris Zhong <[email protected]>
Also known as the Asus Chromebit.
---
would cool to get an Ack from ChromeOS-people concerning the license change to GPL2/X11 - as with the dts before
Also if someone else should be designated as author I would be happy got get a shout about that :-) . I did take Chris as he was the one submitting the initial mickey dts to the chromeos tree.
And of course it would be cool if anyone could test that on an actual mickey device.
Documentation/devicetree/bindings/arm/rockchip.txt | 9 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-mickey.dts | 246 +++++++++++++++++++++ 3 files changed, 256 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-veyron-mickey.dts
Documentation/devicetree/bindings/arm/rockchip.txt +9 -0
@@ -54,6 +54,15 @@ Rockchip platforms device tree bindings "google,veyron-jerry-rev3", "google,veyron-jerry", "google,veyron", "rockchip,rk3288"; +- Google Mickey (Asus Chromebit CS10): + Required root node properties: + - compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7", + "google,veyron-mickey-rev6", "google,veyron-mickey-rev5", + "google,veyron-mickey-rev4", "google,veyron-mickey-rev3", + "google,veyron-mickey-rev2", "google,veyron-mickey-rev1", + "google,veyron-mickey-rev0", "google,veyron-mickey", + "google,veyron", "rockchip,rk3288"; + - Google Minnie (Asus Chromebook Flip C100P): Required root node properties: - compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",
arch/arm/boot/dts/Makefile +1 -0
@@ -527,6 +527,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-veyron-brain.dtb \ rk3288-veyron-jaq.dtb \ rk3288-veyron-jerry.dtb \ + rk3288-veyron-mickey.dtb \ rk3288-veyron-minnie.dtb \ rk3288-veyron-pinky.dtb \ rk3288-veyron-speedy.dtb
arch/arm/boot/dts/rk3288-veyron-mickey.dts new file +246 -0
246 lines not on this page · raw message
Signature · 1 line
2.6.1
PATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
I don't have much luck with patches today ... obviously that is supposed to be mickey in the subject
Am Dienstag, 1. Dezember 2015, 18:16:55 schrieb Heiko St?bner:
Quoted 309 lines
From: Chris Zhong <[email protected]>
Also known as the Asus Chromebit.
Signed-off-by Chris Zhong <[email protected]>Signed-off-by Heiko Stuebner <[email protected]>---
would cool to get an Ack from ChromeOS-people concerning the license change to GPL2/X11 - as with the dts beforeAlso if someone else should be designated as author I would be happy got get a shout about that :-) . I did take Chris as he was the one submitting the initial mickey dts to the chromeos tree.
And of course it would be cool if anyone could test that on an actual mickey device.
Documentation/devicetree/bindings/arm/rockchip.txt | 9 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-mickey.dts | 246 +++++++++++++++++++++ 3 files changed, 256 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-veyron-mickey.dts(quoted diff) +0
-0
b/Documentation/devicetree/bindings/arm/rockchip.txtindex 2f8b35a..2fa0a21 100644Documentation/devicetree/bindings/arm/rockchip.txt +8
-0@@ -54,6 +54,15 @@ Rockchip platforms device tree bindings "google,veyron-jerry-rev3", "google,veyron-jerry", "google,veyron", "rockchip,rk3288"; +- Google Mickey (Asus Chromebit CS10): + Required root node properties: + - compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7", + "google,veyron-mickey-rev6", "google,veyron-mickey-rev5", + "google,veyron-mickey-rev4", "google,veyron-mickey-rev3", + "google,veyron-mickey-rev2", "google,veyron-mickey-rev1", + "google,veyron-mickey-rev0", "google,veyron-mickey", + "google,veyron", "rockchip,rk3288"; + - Google Minnie (Asus Chromebook Flip C100P): Required root node properties: - compatible = "google,veyron-minnie-rev4","google,veyron-minnie-rev3", diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 2f29350..8b49bfc 100644
arch/arm/boot/dts/Makefile +1
-0@@ -527,6 +527,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-veyron-brain.dtb \ rk3288-veyron-jaq.dtb \ rk3288-veyron-jerry.dtb \ + rk3288-veyron-mickey.dtb \ rk3288-veyron-minnie.dtb \ rk3288-veyron-pinky.dtb \ rk3288-veyron-speedy.dtb(quoted diff) +0
-0
b/arch/arm/boot/dts/rk3288-veyron-mickey.dtsnew file mode 100644 index 0000000..365382aarch/arm/boot/dts/rk3288-veyron-mickey.dts new file +246
-0@@ -0,0 +1,246 @@ +/* + * Google Veyron Mickey Rev 0 board device tree source + * + * Copyright 2015 Google, Inc + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; +#include "rk3288-veyron.dtsi" + +/ { + model = "Google Mickey"; + compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7", + "google,veyron-mickey-rev6", "google,veyron-mickey-rev5", + "google,veyron-mickey-rev4", "google,veyron-mickey-rev3", + "google,veyron-mickey-rev2", "google,veyron-mickey-rev1", + "google,veyron-mickey-rev0", "google,veyron-mickey", + "google,veyron", "rockchip,rk3288"; + + vcc_5v: vcc-5v { + vin-supply = <&vcc33_sys>; + }; + + vcc33_io: vcc33_io { + compatible = "regulator-fixed"; + regulator-name = "vcc33_io"; + regulator-always-on; + regulator-boot-on; + vin-supply = <&vcc33_sys>; + }; +}; + +&cpu_thermal { + /delete-node/ trips; + /delete-node/ cooling-maps; + + trips { + cpu_alert_almost_warm: cpu_alert_almost_warm { + temperature = <63000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_warm: cpu_alert_warm { + temperature = <65000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_almost_hot: cpu_alert_almost_hot { + temperature = <80000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_hot: cpu_alert_hot { + temperature = <82000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_hotter: cpu_alert_hotter { + temperature = <84000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_very_hot: cpu_alert_very_hot { + temperature = <85000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_crit: cpu_crit { + temperature = <90000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "critical"; + }; + }; + + cooling-maps { + /* + * After 1st level, throttle the CPU down to as low as 1.4 GHz + * and don't let the GPU go faster than 400 MHz. Note that we + * won't throttle the GPU lower than 400 MHz due to CPU + * heat--we'll let the GPU do the rest itself. + */ + cpu_warm_limit_cpu { + trip = <&cpu_alert_warm>; + cooling-device = + <&cpu0 THERMAL_NO_LIMIT 4>; + }; + + /* + * Add some discrete steps to help throttling system deal + * with the fact that there are two passive cooling devices: + * the CPU and the GPU. + * + * - 1.2 GHz - 1.0 GHz (almost hot) + * - 800 MHz (hot) + * - 800 MHz - 696 MHz (hotter) + * - 696 MHz - min (very hot) + * + * Note: + * - 800 MHz appears to be a "sweet spot" for me. I can run + * some pretty serious workload here and be happy. + * - After 696 MHz we stop lowering voltage, so throttling + * past there is less effective. + */ + cpu_almost_hot_limit_cpu { + trip = <&cpu_alert_almost_hot>; + cooling-device = + <&cpu0 5 6>; + }; + cpu_hot_limit_cpu { + trip = <&cpu_alert_hot>; + cooling-device = + <&cpu0 7 7>; + }; + cpu_hotter_limit_cpu { + trip = <&cpu_alert_hotter>; + cooling-device = + <&cpu0 7 8>; + }; + cpu_very_hot_limit_cpu { + trip = <&cpu_alert_very_hot>; + cooling-device = + <&cpu0 8 THERMAL_NO_LIMIT>; + }; + }; +}; + +&i2c2 { + status = "disabled"; +}; + +&i2c4 { + status = "disabled"; +}; + +&i2s { + status = "okay"; + clock-names = "i2s_hclk", "i2s_clk", "i2s_clk_out"; + clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>, <&cru SCLK_I2S0_OUT>; +}; + +&rk808 { + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>; + dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>, + <&gpio7 15 GPIO_ACTIVE_HIGH>; + + /delete-property/ vcc6-supply; + /delete-property/ vcc12-supply; + + vcc11-supply = <&vcc33_sys>; + + regulators { + /* vcc33_io is sourced directly from vcc33_sys */ + /delete-node/ LDO_REG1; + /delete-node/ LDO_REG7; + + /* This is not a pwren anymore, but the real power supply */ + vdd10_lcd: LDO_REG7 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-name = "vdd10_lcd"; + regulator-suspend-mem-disabled; + }; + + vcc18_lcd: LDO_REG8 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc18_lcd"; + regulator-suspend-mem-disabled; + }; + }; +}; + +&pinctrl { + hdmi { + power_hdmi_on: power-hdmi-on { + rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + pmic { + dvs_1: dvs-1 { + rockchip,pins = <7 12 RK_FUNC_GPIO &pcfg_pull_down>; + }; + + dvs_2: dvs-2 { + rockchip,pins = <7 15 RK_FUNC_GPIO &pcfg_pull_down>; + }; + }; +}; + +&usb_host0_ehci { + status = "disabled"; +}; + +&usb_host1 { + status = "disabled"; +}; + +&vcc50_hdmi { + enable-active-high; + gpio = <&gpio7 11 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&power_hdmi_on>; +};
PATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
In reply to Heiko StübnerQuoted 9 lines · Heiko St?bner
From: Chris Zhong <[email protected]>
Also known as the Asus Chromebit.
Signed-off-by Chris Zhong <[email protected]>Signed-off-by Heiko Stuebner <[email protected]>---
would cool to get an Ack from ChromeOS-people concerning the license change to GPL2/X11 - as with the dts before
For the license change:
Quoted 3 lines
Also if someone else should be designated as author I would be happy got get a shout about that :-) . I did take Chris as he was the one submitting the initial mickey dts to the chromeos tree.
Looks OK to me, FWIW.
Quoted 2 lines
And of course it would be cool if anyone could test that on an actual mickey device.
Sorry, didn't test!
Quoted 5 lines
Documentation/devicetree/bindings/arm/rockchip.txt | 9 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-mickey.dts | 246 +++++++++++++++++++++ 3 files changed, 256 insertions(+) create mode 100644 arch/arm/boot/dts/rk3288-veyron-mickey.dts
...
Brian
PATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
In reply to Heiko StübnerHi Heiko
? 2015?12?02? 01:16, Heiko St?bner ??:
Quoted 6 lines
From: Chris Zhong <[email protected]>
Also known as the Asus Chromebit.
Signed-off-by Chris Zhong <[email protected]>Signed-off-by Heiko Stuebner <[email protected]>
Tested on my mickey board with chrome os on kernel 4.4 -rc3.
localhost / # cat /proc/version
Linux version 4.4.0-rc3+ (wxt at ubuntu) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #59 SMP Thu Dec 3 17:32:10 CST 2015
.....but,
reboot long long test, that's seem mmc tune has a issue.
2.630892] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd
response 0x900, card status 0x0
[ 2.631006] mmcblk0: error -110 sending status command, retrying [ 2.631018] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0 [ 2.631703] mmcblk0: unable to read partition table
...
Anyway, the dts is good to support mickey machine. I think the mmc tune is not prefect in mainline.
Quoted 301 lines
---
would cool to get an Ack from ChromeOS-people concerning the license change to GPL2/X11 - as with the dts beforeAlso if someone else should be designated as author I would be happy got get a shout about that :-) . I did take Chris as he was the one submitting the initial mickey dts to the chromeos tree.
And of course it would be cool if anyone could test that on an actual mickey device.
Documentation/devicetree/bindings/arm/rockchip.txt | 9 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3288-veyron-mickey.dts | 246 +++++++++++++++++++++ 3 files changed, 256 insertions(+)create mode 100644
arch/arm/boot/dts/rk3288-veyron-mickey.dtsDocumentation/devicetree/bindings/arm/rockchip.txt +9
-0@@ -54,6 +54,15 @@ Rockchip platforms device tree bindings "google,veyron-jerry-rev3", "google,veyron-jerry", "google,veyron", "rockchip,rk3288"; +- Google Mickey (Asus Chromebit CS10): + Required root node properties: + - compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7", + "google,veyron-mickey-rev6", "google,veyron-mickey-rev5", + "google,veyron-mickey-rev4", "google,veyron-mickey-rev3", + "google,veyron-mickey-rev2", "google,veyron-mickey-rev1", + "google,veyron-mickey-rev0", "google,veyron-mickey", + "google,veyron", "rockchip,rk3288"; + - Google Minnie (Asus Chromebook Flip C100P): Required root node properties: - compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",arch/arm/boot/dts/Makefile +1
-0@@ -527,6 +527,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ rk3288-veyron-brain.dtb \ rk3288-veyron-jaq.dtb \ rk3288-veyron-jerry.dtb \ + rk3288-veyron-mickey.dtb \ rk3288-veyron-minnie.dtb \ rk3288-veyron-pinky.dtb \ rk3288-veyron-speedy.dtbarch/arm/boot/dts/rk3288-veyron-mickey.dts new file +246
-0@@ -0,0 +1,246 @@ +/* + * Google Veyron Mickey Rev 0 board device tree source + * + * Copyright 2015 Google, Inc + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; +#include "rk3288-veyron.dtsi" + +/ { + model = "Google Mickey"; + compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7", + "google,veyron-mickey-rev6", "google,veyron-mickey-rev5", + "google,veyron-mickey-rev4", "google,veyron-mickey-rev3", + "google,veyron-mickey-rev2", "google,veyron-mickey-rev1", + "google,veyron-mickey-rev0", "google,veyron-mickey", + "google,veyron", "rockchip,rk3288"; + + vcc_5v: vcc-5v { + vin-supply = <&vcc33_sys>; + }; + + vcc33_io: vcc33_io { + compatible = "regulator-fixed"; + regulator-name = "vcc33_io"; + regulator-always-on; + regulator-boot-on; + vin-supply = <&vcc33_sys>; + }; +}; + +&cpu_thermal { + /delete-node/ trips; + /delete-node/ cooling-maps; + + trips { + cpu_alert_almost_warm: cpu_alert_almost_warm { + temperature = <63000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_warm: cpu_alert_warm { + temperature = <65000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_almost_hot: cpu_alert_almost_hot { + temperature = <80000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_hot: cpu_alert_hot { + temperature = <82000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_hotter: cpu_alert_hotter { + temperature = <84000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_alert_very_hot: cpu_alert_very_hot { + temperature = <85000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + cpu_crit: cpu_crit { + temperature = <90000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "critical"; + }; + }; + + cooling-maps { + /* + * After 1st level, throttle the CPU down to as low as 1.4 GHz + * and don't let the GPU go faster than 400 MHz. Note that we + * won't throttle the GPU lower than 400 MHz due to CPU + * heat--we'll let the GPU do the rest itself. + */ + cpu_warm_limit_cpu { + trip = <&cpu_alert_warm>; + cooling-device = + <&cpu0 THERMAL_NO_LIMIT 4>; + }; + + /* + * Add some discrete steps to help throttling system deal + * with the fact that there are two passive cooling devices: + * the CPU and the GPU. + * + * - 1.2 GHz - 1.0 GHz (almost hot) + * - 800 MHz (hot) + * - 800 MHz - 696 MHz (hotter) + * - 696 MHz - min (very hot) + * + * Note: + * - 800 MHz appears to be a "sweet spot" for me. I can run + * some pretty serious workload here and be happy. + * - After 696 MHz we stop lowering voltage, so throttling + * past there is less effective. + */ + cpu_almost_hot_limit_cpu { + trip = <&cpu_alert_almost_hot>; + cooling-device = + <&cpu0 5 6>; + }; + cpu_hot_limit_cpu { + trip = <&cpu_alert_hot>; + cooling-device = + <&cpu0 7 7>; + }; + cpu_hotter_limit_cpu { + trip = <&cpu_alert_hotter>; + cooling-device = + <&cpu0 7 8>; + }; + cpu_very_hot_limit_cpu { + trip = <&cpu_alert_very_hot>; + cooling-device = + <&cpu0 8 THERMAL_NO_LIMIT>; + }; + }; +}; + +&i2c2 { + status = "disabled"; +}; + +&i2c4 { + status = "disabled"; +}; + +&i2s { + status = "okay"; + clock-names = "i2s_hclk", "i2s_clk", "i2s_clk_out"; + clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>, <&cru SCLK_I2S0_OUT>; +}; + +&rk808 { + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>; + dvs-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>, + <&gpio7 15 GPIO_ACTIVE_HIGH>; + + /delete-property/ vcc6-supply; + /delete-property/ vcc12-supply; + + vcc11-supply = <&vcc33_sys>; + + regulators { + /* vcc33_io is sourced directly from vcc33_sys */ + /delete-node/ LDO_REG1; + /delete-node/ LDO_REG7; + + /* This is not a pwren anymore, but the real power supply */ + vdd10_lcd: LDO_REG7 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-name = "vdd10_lcd"; + regulator-suspend-mem-disabled; + }; + + vcc18_lcd: LDO_REG8 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc18_lcd"; + regulator-suspend-mem-disabled; + }; + }; +}; + +&pinctrl { + hdmi { + power_hdmi_on: power-hdmi-on { + rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + pmic { + dvs_1: dvs-1 { + rockchip,pins = <7 12 RK_FUNC_GPIO &pcfg_pull_down>; + }; + + dvs_2: dvs-2 { + rockchip,pins = <7 15 RK_FUNC_GPIO &pcfg_pull_down>; + }; + }; +}; + +&usb_host0_ehci { + status = "disabled"; +}; + +&usb_host1 { + status = "disabled"; +}; + +&vcc50_hdmi { + enable-active-high; + gpio = <&gpio7 11 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&power_hdmi_on>; +};
PATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
Hi Caesar,
Am Donnerstag, 3. Dezember 2015, 18:27:27 schrieb Caesar Wang:
Quoted 9 lines
? 2015?12?02? 01:16, Heiko St?bner ??:
Quoted 6 lines
From: Chris Zhong <[email protected]>
Also known as the Asus Chromebit.
Signed-off-by Chris Zhong <[email protected]>Signed-off-by Heiko Stuebner <[email protected]>Tested-by Caesar Wang <[email protected]>
thanks :-)
Quoted 9 lines
Tested on my mickey board with chrome os on kernel 4.4 -rc3.
localhost / # cat
/proc/version
Linux version 4.4.0-rc3+ (wxt at ubuntu) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #59 SMP Thu Dec 3 17:32:10 CST 2015.....but,
reboot long long test, that's seem mmc tune has a issue.
Quoted 7 lines
2.630892] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [ 2.631006] mmcblk0: error -110 sending status command, retrying [ 2.631018] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0 [ 2.631703] mmcblk0: unable to read partition table...
Could you try if what we do on Minnie fixes that error (disabling tuning for now) - i.e. adding the following to the Mickey dts:
&emmc {
/delete-property/mmc-hs200-1_8v;
};Quoted 2 lines
Anyway, the dts is good to support mickey machine. I think the mmc tune is not prefect in mainline.
yeah, it seems we still have some issues.
Although it seems only the disney-mice seem affected ;-) [minnie and mickey]. Pinky, Brain, Speedy, Jaq all seem to work somehow - at least I haven't gotten any reports about that
Thanks
Heiko
PATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
Hi Heiko,
? 2015?12?03? 18:44, Heiko St?bner ??:
Quoted 30 lines
Hi Caesar,
Am Donnerstag, 3. Dezember 2015, 18:27:27 schrieb Caesar Wang:
Quoted 8 lines
? 2015?12?02? 01:16, Heiko St?bner ??:
Quoted 6 lines
From: Chris Zhong <[email protected]>
Also known as the Asus Chromebit.
Signed-off-by Chris Zhong <[email protected]>Signed-off-by Heiko Stuebner <[email protected]>Tested-by Caesar Wang <[email protected]>thanks :-)
Quoted 9 lines
Tested on my mickey board with chrome os on kernel 4.4 -rc3.
localhost / # cat
/proc/version
Linux version 4.4.0-rc3+ (wxt at ubuntu) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #59 SMP Thu Dec 3 17:32:10 CST 2015.....but,
reboot long long test, that's seem mmc tune has a issue.Quoted 7 lines
2.630892] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [ 2.631006] mmcblk0: error -110 sending status command, retrying [ 2.631018] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0 [ 2.631703] mmcblk0: unable to read partition table...
Quoted 8 lines
Could you try if what we do on Minnie fixes that error (disabling tuning for now) - i.e. adding the following to the Mickey dts:
&emmc { /delete-property/mmc-hs200-1_8v; };
Yep, maybe we remove this node firstly but someone fix the emmc tune issues.
Quoted 7 lines
Quoted 2 lines
Anyway, the dts is good to support mickey machine. I think the mmc tune is not prefect in mainline.
yeah, it seems we still have some issues.
Although it seems only the disney-mice seem affected ;-) [minnie and mickey]. Pinky, Brain, Speedy, Jaq all seem to work somehow - at least I haven't gotten any reports about that
Cc shawn,
Maybe, Shawn at RK has the interesting in debuging this issue.:-)
Quoted 4 lines
Thanks
Heiko
Signature · 1 line
caesar wang | software engineer | wxt at rock-chip.com
Heiko Stübner
maintainerPATCH 3/3 ARM: dts: rockchip: add veyron-minnie board
Hi Caesar, Shawn,
Am Donnerstag, 3. Dezember 2015, 19:01:00 schrieb Caesar Wang:
Quoted 17 lines
? 2015?12?03? 18:44, Heiko St?bner ??:
Quoted 16 lines
Am Donnerstag, 3. Dezember 2015, 18:27:27 schrieb Caesar Wang:
Quoted 11 lines
.....but,
reboot long long test, that's seem mmc tune has a issue.2.630892] mmcblk0: error -84 transferring data, sector 0, nr 8, cmdresponse
0x900, card status0x0[ 2.631006] mmcblk0: error -110 sending status command, retrying [ 2.631018] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0 [ 2.631703] mmcblk0: unable to read partition table...
Could you try if what we do on Minnie fixes that error (disabling tuning for now) - i.e. adding the following to the Mickey dts:
Quoted 7 lines
Quoted 5 lines
&emmc {
/delete-property/mmc-hs200-1_8v;};
Yep, maybe we remove this node firstly but someone fix the emmc tune issues.
yep, that is definitly the plan. I've now also done more than a dozen reboot tests on my brain board including running hdparm-speedtests on the emmc there. Tuning and all reads did run without any hickups, so this really seems to be somehow limited.
Quoted 11 lines
Quoted 8 lines
Quoted 2 lines
Anyway, the dts is good to support mickey machine. I think the mmc tune is not prefect in mainline.
yeah, it seems we still have some issues.
Although it seems only the disney-mice seem affected ;-) [minnie and mickey]. Pinky, Brain, Speedy, Jaq all seem to work somehow - at least I haven't gotten any reports about that
Cc shawn,
Maybe, Shawn at RK has the interesting in debuging this issue.:-)
Strangely on the ChromeOS kernel tuning on Minnie seems to work ok. I already checked the code somewhat and the core handling seems to be the same - like the phase clocks and the tuning algorithm.
The only slight difference is that mainline is using mmc_send_tuning() instead of building the packet by hand.
But at least on my Minnie the phases the emmc gets tuned to are always differing somehow: (mainline: 216-218, chromeos: 198-201) while on my jerry the variance is not as big (mainline 176, chromeos: 172).
Some more comparisons I did on Minnie:
sdmmc: phase 197 on both mainline and chromeos
wifi: around phase 214 on mainline and 204 on chromeos
So at least the sdmmc host seems pretty stable in its phase and the difference on wifi is smaller than with the emmc - not sure if that helps though :-)
I'll also try to look more into that issue, but would be glad to hear other bright ideas :-)
Thanks
Heiko
PATCH 1/3 ARM: dts: rockchip: make sure edp_24m is associated to xin24m on veyron
In reply to Heiko StübnerAm Dienstag, 1. Dezember 2015, 18:14:27 schrieb Heiko St?bner:
applied all three patches to my dts32 branch for 4.5, after disabling emmc tuning on mickey (in a similar fashion as on minnie) for the short term.
Quoted 38 lines
The edp-24m clock has two possible sources: the 24MHz oscillator as well as an external 27MHz input. The power-on-default is the 27MHz clock which is not supplied on all Rockchip boards. While on all current boards and also all Veyron Chromebooks the bootloader seems to adapt the muxing to the internal source, this doesn't seem to be the case on headless veyron devices like brain and mickey making the edp-24m clock an orphan. On the hardware side the 27m input also is not connected at all.
With the upcoming deferral of orphan-clocks this results in the power- domain code deferring, as it cannot request the needed clock and if the synchronous reset is sucessfullat all in this case is also unknown.
So fix that by making sure, the edp-24m clock is muxed to the internal 24MHz oscillator at all times.
Signed-off-by Heiko Stuebner <[email protected]>---
It seems I had some issues sending, sorry about the double-mails.arch/arm/boot/dts/rk3288-veyron.dtsi | 5 +++++ 1 file changed, 5 insertions(+)(quoted diff) +0
-0
b/arch/arm/boot/dts/rk3288-veyron.dtsiindex 5e61f07..9fce91f 100644arch/arm/boot/dts/rk3288-veyron.dtsi +5
-0@@ -340,6 +340,11 @@ i2c-scl-rising-time-ns = <1000>; }; +&power { + assigned-clocks = <&cru SCLK_EDP_24M>; + assigned-clock-parents = <&xin24m>; +}; + &pwm1 { status = "okay"; };