Re: issues with suspend on Dell XPS 13 2-in-1
El vie, 12-10-2018 a las 17:46 +, mario.limoncie...@dell.com
escribió:
> > -Original Message-
> > From: Dennis Gilmore
> > Sent: Friday, October 12, 2018 8:39 AM
> > To: Pandruvada, Srinivas
> > Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org;
> > Limonciello, Mario
> > Subject: Re: issues with suspend on Dell XPS 13 2-in-1
> >
>
> It appears I'm being added to this thread late. Can you give me some
> more context?
> Which XPS 2-in-1 is this (model number)? And what are the issues?
>
> I'm "guessing" high power consumption over S2I?
Sorry we had a discussion back in April about high power consumption
when suspending. The conversation stopped when the debugging steps did
not work. Which turns out to be due to secure boot. I have just dealt
with it by shutting down, but as I am currently travelling it annoyed
me enough to try and figure out what is happening again. I have a 9635
and esentially I get the same battery use regardless of if I suspend or
not.
Dennis
> >
> > El jue, 26-04-2018 a las 15:09 +, Pandruvada, Srinivas
> > escribió:
> > > On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote:
> > > > Hi Srinivas,
> > > >
> > > > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas
> > > > escribió:
> > > > > Hi Dennis,
> > > > >
> > > > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote:
> > > > > > Hi Srinivas,
> > > > > >
> > > > > > Yes I have latest bios, I have version 1.3.1 that was
> > > > > > released
> > > > > > on
> > > > > > 18th
> > > > > > of Feb.
> > > > >
> > > > > Can you try these commands and repeat the test?
> > > > >
> > > > > # cd /sys/kernel/debug/pmc_core/
> > > > > # for i in {0..32}; do echo $i > ltr_ignore; done
> > > >
> > > > # for i in {0..32}; do echo $i > ltr_ignore; done
> > > > -bash: ltr_ignore: Operación no permitida
> >
> > After some digging i figured out that the patches fedora has for
> > secureboot caused the access to ltr_ignore to not work.
> >
>
> If you are trying to debug high power consumption and those patches
> are causing
> problems, can you please remove those patches?
>
> LTR ignoring is an important debugging tactic to find problems with
> S2I consuming
> too much power.
>
> Additionally if you can read
> /sys/kernel/debug/pmc_core/pch_ip_power_gating_status
> That may help to point out what is wrong.
>
> > # turbostat
> > turbostat version 18.07.27 - Len Brown
> > CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping
> > 0x6:8e:9
> > (6:142:9)
> > CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM HT TM
> > CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow,
> > HWPepp,
> > No-HWPpkg, EPB
> > cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MWAIT PREFETCH
> > TURBO)
> > CPUID(7): SGX
> > cpu1: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked )
> > CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0
> > TSC: 1608 MHz (2400 Hz * 134 / 2 / 100)
> > CPUID(0x16): base_mhz: 1600 max_mhz: 3600 bus_mhz: 100
> > cpu1: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination
> > DISable-
> > EPB DISable-OOB)
> > RAPL: 58254 sec. Joule Counter Range, at 4 Watts
> > cpu1: MSR_PLATFORM_INFO: 0x804043df1011000
> > 4 * 100.0 = 400.0 MHz max efficiency frequency
> > 16 * 100.0 = 1600.0 MHz base frequency
> > cpu1: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion: DISabled)
> > cpu1: MSR_TURBO_RATIO_LIMIT: 0x2224
> > 34 * 100.0 = 3400.0 MHz max turbo 4 active cores
> > 34 * 100.0 = 3400.0 MHz max turbo 3 active cores
> > 34 * 100.0 = 3400.0 MHz max turbo 2 active cores
> > 36 * 100.0 = 3600.0 MHz max turbo 1 active cores
> > cpu1: MSR_CONFIG_TDP_NOMINAL: 0x000d (base_ratio=13)
> > cpu1: MSR_CONFIG_TDP_LEVEL_1: 0x0006001c (PKG_MIN_PWR_LVL1=0
> > PKG_MAX_PWR_LVL1=0 LVL1_RATIO=6 PKG_TDP_LVL1=28)
> > cpu1: MSR_CONFIG_TDP_LEVEL_2: 0x00100038 (PKG_MIN_PWR_LVL2=0
> > PKG_MAX_PWR_LVL2=0 LVL2_RATIO=16 PKG_TDP_LVL2=56)
> > cpu1: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0)
> > cpu1: MSR_TURBO_ACTIVATION_RATIO: 0x000c
> > (MAX_NON_TURBO_RATIO=12
> > lock=0)
> > cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3,
> > UNdemote-
> > C1,
> > demote-C3, demote-C1, locked, pkg-cstate-limit=8 (unlimited))
> > c
Re: issues with suspend on Dell XPS 13 2-in-1
El jue, 26-04-2018 a las 15:09 +, Pandruvada, Srinivas escribió:
> On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote:
> > Hi Srinivas,
> >
> > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas
> > escribió:
> > > Hi Dennis,
> > >
> > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote:
> > > > Hi Srinivas,
> > > >
> > > > Yes I have latest bios, I have version 1.3.1 that was released
> > > > on
> > > > 18th
> > > > of Feb.
> > >
> > > Can you try these commands and repeat the test?
> > >
> > > # cd /sys/kernel/debug/pmc_core/
> > > # for i in {0..32}; do echo $i > ltr_ignore; done
> >
> > # for i in {0..32}; do echo $i > ltr_ignore; done
> > -bash: ltr_ignore: Operación no permitida
After some digging i figured out that the patches fedora has for
secureboot caused the access to ltr_ignore to not work.
# turbostat
turbostat version 18.07.27 - Len Brown
CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping 0x6:8e:9
(6:142:9)
CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM HT TM
CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp,
No-HWPpkg, EPB
cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MWAIT PREFETCH TURBO)
CPUID(7): SGX
cpu1: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked )
CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0
TSC: 1608 MHz (2400 Hz * 134 / 2 / 100)
CPUID(0x16): base_mhz: 1600 max_mhz: 3600 bus_mhz: 100
cpu1: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination DISable-
EPB DISable-OOB)
RAPL: 58254 sec. Joule Counter Range, at 4 Watts
cpu1: MSR_PLATFORM_INFO: 0x804043df1011000
4 * 100.0 = 400.0 MHz max efficiency frequency
16 * 100.0 = 1600.0 MHz base frequency
cpu1: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion: DISabled)
cpu1: MSR_TURBO_RATIO_LIMIT: 0x2224
34 * 100.0 = 3400.0 MHz max turbo 4 active cores
34 * 100.0 = 3400.0 MHz max turbo 3 active cores
34 * 100.0 = 3400.0 MHz max turbo 2 active cores
36 * 100.0 = 3600.0 MHz max turbo 1 active cores
cpu1: MSR_CONFIG_TDP_NOMINAL: 0x000d (base_ratio=13)
cpu1: MSR_CONFIG_TDP_LEVEL_1: 0x0006001c (PKG_MIN_PWR_LVL1=0
PKG_MAX_PWR_LVL1=0 LVL1_RATIO=6 PKG_TDP_LVL1=28)
cpu1: MSR_CONFIG_TDP_LEVEL_2: 0x00100038 (PKG_MIN_PWR_LVL2=0
PKG_MAX_PWR_LVL2=0 LVL2_RATIO=16 PKG_TDP_LVL2=56)
cpu1: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0)
cpu1: MSR_TURBO_ACTIVATION_RATIO: 0x000c (MAX_NON_TURBO_RATIO=12
lock=0)
cpu1: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3, UNdemote-C1,
demote-C3, demote-C1, locked, pkg-cstate-limit=8 (unlimited))
cpu1: POLL: CPUIDLE CORE POLL IDLE
cpu1: C1: MWAIT 0x00
cpu1: C1E: MWAIT 0x01
cpu1: C3: MWAIT 0x10
cpu1: C6: MWAIT 0x20
cpu1: C7s: MWAIT 0x33
cpu1: C8: MWAIT 0x40
cpu1: C9: MWAIT 0x50
cpu1: C10: MWAIT 0x60
cpu1: cpufreq driver: intel_pstate
cpu1: cpufreq governor: powersave
cpufreq intel_pstate no_turbo: 0
cpu1: MSR_MISC_FEATURE_CONTROL: 0x (L2-Prefetch L2-Prefetch-
pair L1-Prefetch L1-IP-Prefetch)
cpu0: MSR_PM_ENABLE: 0x0001 (HWP)
cpu0: MSR_HWP_CAPABILITIES: 0x01070d24 (high 36 guar 13 eff 7 low 1)
cpu0: MSR_HWP_REQUEST: 0x80002404 (min 4 max 36 des 0 epp 0x80 window
0x0 pkg 0x0)
cpu0: MSR_HWP_INTERRUPT: 0x (Dis_Guaranteed_Perf_Change,
Dis_Excursion_Min)
cpu0: MSR_HWP_STATUS: 0x (No-Guaranteed_Perf_Change, No-
Excursion_Min)
cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0006 (balanced)
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.61 Joules,
0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x0024 (4 W TDP, RAPL 0 - 0 W, 0.00
sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x420078009c8048 (UNlocked)
cpu0: PKG Limit #1: ENabled (9.00 Watts, 24.00 sec, clamp
DISabled)
cpu0: PKG Limit #2: DISabled (15.00 Watts, 0.002441* sec, clamp
DISabled)
cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de (UNlocked)
cpu0: DRAM Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
DISabled)
cpu0: MSR_PP0_POLICY: 0
cpu0: MSR_PP0_POWER_LIMIT: 0x (UNlocked)
cpu0: Cores Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
DISabled)
cpu0: MSR_PP1_POLICY: 0
cpu0: MSR_PP1_POWER_LIMIT: 0x (UNlocked)
cpu0: GFX Limit: DISabled (0.00 Watts, 0.000977 sec, clamp
DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x0a640080 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x882e0808 (54 C)
cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x0003 (100 C, 100 C)
cpu1: MSR_PKGC3_IRTL: 0x884e (valid, 79872 ns)
cpu1: MSR_PKGC6_IRTL: 0x8876 (valid, 120832 ns)
cpu1: MSR_PKGC7_IRTL: 0x8894 (valid, 151552 ns)
cpu1: MSR_PKGC8_IRTL: 0x88fa (valid, 256000 ns)
cpu1: MSR_PKGC9_IRTL: 0x894c (valid, 339968 ns)
cpu1: MSR_PKGC10_IRTL: 0x8bf2 (valid, 1034240 ns)
CoreCPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ SMI POLL
C1 C1E C3 C6 C7s C8 C9 C10 POLL%
C1% C1E%C
[PATCH V4] ARM: dts: armada388-helios4
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
changes since v2
remove commented out nodes based on feedback
changes since v3
update copyright info for the dts based on a request from kobol
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 313 +++
2 files changed, 314 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts
b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index ..705adfa8c680
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017 Aditya Prayoga
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x8000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+
[PATCH V3] ARM: dts: armada388-helios4
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
changes since v2
remove commented out nodes based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 313 +++
2 files changed, 314 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts
b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index ..59048740ae06
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x8000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+
[PATCH V2] ARM: dts: armada388-helios4
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "kobol,helios4"
Signed-off-by: Dennis Gilmore
---
changes since first submission
change solidrun to kobol in compatible line based on feedback
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 315 +++
2 files changed, 316 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts
b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index ..16026bedc380
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "kobol,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x8000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
[PATCH] ARM: dts: armada388-helios4
The helios4 is a Armada388 based nas board designed by SolidRun and
based on their SOM. It is sold by kobol.io the dts file came from
https://raw.githubusercontent.com/armbian/build/master/patch/kernel/mvebu-default/95-helios4-device-tree.patch
I added a SPDX license line to match the clearfog it says it was based
on and a compatible line for "solidrun,helios4"
Signed-off-by: Dennis Gilmore
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-helios4.dts | 315 +++
2 files changed, 316 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-helios4.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..490bfd586198 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1123,6 +1123,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
+ armada-388-helios4.dtb \
armada-388-rd.dtb
dtb-$(CONFIG_MACH_ARMADA_39X) += \
armada-398-db.dtb
diff --git a/arch/arm/boot/dts/armada-388-helios4.dts
b/arch/arm/boot/dts/armada-388-helios4.dts
new file mode 100644
index ..a6d6996e1378
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-helios4.dts
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Helios4
+ * based on SolidRun Clearfog revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2017
+ *
+ */
+
+/dts-v1/;
+#include "armada-388.dtsi"
+#include "armada-38x-solidrun-microsom.dtsi"
+
+/ {
+ model = "Helios4";
+ compatible = "solidrun,helios4", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x8000>; /* 2 GB */
+ };
+
+ aliases {
+ /* So that mvebu u-boot can update the MAC addresses */
+ ethernet1 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_12v: regulator-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "power_brick_12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_hdd: regulator-5v-hdd {
+ compatible = "regulator-fixed";
+ regulator-name = "5V_HDD";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <®_12v>;
+ };
+
+ reg_5p0v_usb: regulator-5v-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "USB-PWR";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ regulator-always-on;
+ enable-active-high;
+ gpio = <&expander0 6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <®_12v>;
+ };
+
+ system-leds {
+ compatible = "gpio-leds";
+ status-led {
+ label = "helios4:green:status";
+ gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ fault-led {
+ label = "helios4:red:fault";
+ gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
+ default-state = "keep";
+ };
+ };
+
+ io-leds {
+ compatible = "gpio-leds";
+ sata1-led {
+ label = "helios4:green:ata1";
+ gpios = <&gpio1 17 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata1";
+ default-state = "off";
+ };
+ sata2-led {
+ label = "helios4:green:ata2";
+ gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "ata2";
+ default-s
Re: issues with suspend on Dell XPS 13 2-in-1
El jue, 26-04-2018 a las 15:09 +, Pandruvada, Srinivas escribió:
> On Thu, 2018-04-26 at 07:42 -0500, Dennis Gilmore wrote:
> > Hi Srinivas,
> >
> > El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas
> > escribió:
> > > Hi Dennis,
> > >
> > > On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote:
> > > > Hi Srinivas,
> > > >
> > > > Yes I have latest bios, I have version 1.3.1 that was released
> > > > on
> > > > 18th
> > > > of Feb.
> > >
> > > Can you try these commands and repeat the test?
> > >
> > > # cd /sys/kernel/debug/pmc_core/
> > > # for i in {0..32}; do echo $i > ltr_ignore; done
> >
> > # for i in {0..32}; do echo $i > ltr_ignore; done
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> > -bash: ltr_ignore: Operación no permitida
> >
> > should I go ahead and run the test even though writing to
> > ltr_ignore
> > failed?
>
> Strange. Do you have any issue with the permissions?
> # cd /sys/kernel/debug/pmc_core/
> # ls -l
# ls -l
total 0
-rw-r--r--. 1 root root 0 abr 24 17:27 ltr_ignore
-r--r--r--. 1 root root 0 abr 24 17:27
mphy_core_lanes_power_gating_status
-r--r--r--. 1 root root 0 abr 24 17:27 pch_ip_power_gating_status
-r--r--r--. 1 root root 0 abr 24 17:27 pll_status
-r--r--r--. 1 root root 0 abr 24 17:27 slp_s0_residency_usec
I have rw permissions selinux is in permissive mode currently
Thanks
Dennis
> Do you have rw permissions?
>
> Thanks,
> Srinivas
>
> >
> > Dennis
> >
> > > Thanks,
> > > Srinivas
> > >
> > > >
> > > > Dennis
> > > >
> > > > El jue, 26-04-2018 a las 02:13 +, Pandruvada, Srinivas
> > > > escribió:
> > > > >
> > > > > I see around 43% PC10 residency with power drop of 0.7W.
> > > > > Do you have the latest BIOS of Dell 9365?
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Srinivas
> > > > >
> > > > > On Fri, 2018-04-20 at 08:36 -0500, Dennis Gilmore wrote:
> > > > > > Here is the full output
> > > > > >
> > > > > > # turbostat
> > > > > > turbostat version 17.06.23 - Len Brown
> > > > > > CPUID(0): GenuineIntel 22 CPUID levels;
> > > > > > family:model:stepping
> > > > > > 0x6:8e:9 (6:142:9)
> > > > > > CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM TM
> > > > > > CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify,
> > > > > > HWPwindow,
> > > > > > HWPepp, No-HWPpkg, EPB
> > > > > > cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT
> > > > > > PREFETCH
> > > > > > TURBO)
> > > > > > CPUID(7): SGX
> > > > > > cpu0: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked )
> > > > > > CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0
&g
Re: issues with suspend on Dell XPS 13 2-in-1
Hi Srinivas,
El jue, 26-04-2018 a las 05:34 +, Pandruvada, Srinivas escribió:
> Hi Dennis,
>
> On Wed, 2018-04-25 at 22:06 -0500, Dennis Gilmore wrote:
> > Hi Srinivas,
> >
> > Yes I have latest bios, I have version 1.3.1 that was released on
> > 18th
> > of Feb.
>
> Can you try these commands and repeat the test?
>
> # cd /sys/kernel/debug/pmc_core/
> # for i in {0..32}; do echo $i > ltr_ignore; done
# for i in {0..32}; do echo $i > ltr_ignore; done
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
-bash: ltr_ignore: Operación no permitida
should I go ahead and run the test even though writing to ltr_ignore
failed?
Dennis
> Thanks,
> Srinivas
>
> >
> > Dennis
> >
> > El jue, 26-04-2018 a las 02:13 +, Pandruvada, Srinivas
> > escribió:
> > >
> > > I see around 43% PC10 residency with power drop of 0.7W.
> > > Do you have the latest BIOS of Dell 9365?
> > >
> > >
> > > Thanks,
> > > Srinivas
> > >
> > > On Fri, 2018-04-20 at 08:36 -0500, Dennis Gilmore wrote:
> > > > Here is the full output
> > > >
> > > > # turbostat
> > > > turbostat version 17.06.23 - Len Brown
> > > > CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping
> > > > 0x6:8e:9 (6:142:9)
> > > > CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM TM
> > > > CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow,
> > > > HWPepp, No-HWPpkg, EPB
> > > > cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT
> > > > PREFETCH
> > > > TURBO)
> > > > CPUID(7): SGX
> > > > cpu0: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked )
> > > > CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0
> > > > TSC: 1608 MHz (2400 Hz * 134 / 2 / 100)
> > > > CPUID(0x16): base_mhz: 1600 max_mhz: 3600 bus_mhz: 100
> > > > cpu0: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination
> > > > DISable-EPB DISable-OOB)
> > > > RAPL: 58254 sec. Joule Counter Range, at 4 Watts
> > > > cpu0: MSR_PLATFORM_INFO: 0x804043df1011000
> > > > 4 * 100.0 = 400.0 MHz max efficiency frequency
> > > > 16 * 100.0 = 1600.0 MHz base frequency
> > > > cpu0: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion:
> > > > DISabled)
> > > > cpu0: MSR_TURBO_RATIO_LIMIT: 0x2224
> > > > 34 * 100.0 = 3400.0 MHz max turbo 4 active cores
> > > > 34 * 100.0 = 3400.0 MHz max turbo 3 active cores
> > > > 34 * 100.0 = 3400.0 MHz max turbo 2 active cores
> > > > 36 * 100.0 = 3600.0 MHz max turbo 1 active cores
> > > > cpu0: MSR_CONFIG_TDP_NOMINAL: 0x000d (base_ratio=13)
> > > > cpu0: MSR_CONFIG_TDP_LEVEL_1: 0x0006001c (PKG_MIN_PWR_LVL1=0
> > > > PKG_MAX_PWR_LVL1=0 LVL1_RATIO=6 PKG_TDP_LVL1=28)
> > > > cpu0: MSR_CONFIG_TDP_LEVEL_2: 0x00100038 (PKG_MIN_PWR_LVL2=0
> > > > PKG_MAX_PWR_LVL2=0 LVL2_RATIO=16 PKG_TDP_LVL2=56)
> > > > cpu0: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0)
> > > > cpu0: MSR_TURBO_ACTIVATION_RATIO: 0x000c
> > > > (MAX_NON_TURBO_RATIO=12 lock=0)
> > > > cpu0: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3,
> > > > UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=8:
> > > >
Re: issues with suspend on Dell XPS 13 2-in-1
Hi Srinivas, Yes I have latest bios, I have version 1.3.1 that was released on 18th of Feb. Dennis El jue, 26-04-2018 a las 02:13 +, Pandruvada, Srinivas escribió: > > I see around 43% PC10 residency with power drop of 0.7W. > Do you have the latest BIOS of Dell 9365? > > > Thanks, > Srinivas > > On Fri, 2018-04-20 at 08:36 -0500, Dennis Gilmore wrote: > > Here is the full output > > > > # turbostat > > turbostat version 17.06.23 - Len Brown > > CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping > > 0x6:8e:9 (6:142:9) > > CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM TM > > CPUID(6): APERF, TURBO, DTS, PTM, HWP, HWPnotify, HWPwindow, > > HWPepp, No-HWPpkg, EPB > > cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST No-MWAIT PREFETCH > > TURBO) > > CPUID(7): SGX > > cpu0: MSR_IA32_FEATURE_CONTROL: 0xff07 (Locked ) > > CPUID(0x15): eax_crystal: 2 ebx_tsc: 134 ecx_crystal_hz: 0 > > TSC: 1608 MHz (2400 Hz * 134 / 2 / 100) > > CPUID(0x16): base_mhz: 1600 max_mhz: 3600 bus_mhz: 100 > > cpu0: MSR_MISC_PWR_MGMT: 0x00401cc0 (ENable-EIST_Coordination > > DISable-EPB DISable-OOB) > > RAPL: 58254 sec. Joule Counter Range, at 4 Watts > > cpu0: MSR_PLATFORM_INFO: 0x804043df1011000 > > 4 * 100.0 = 400.0 MHz max efficiency frequency > > 16 * 100.0 = 1600.0 MHz base frequency > > cpu0: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion: DISabled) > > cpu0: MSR_TURBO_RATIO_LIMIT: 0x2224 > > 34 * 100.0 = 3400.0 MHz max turbo 4 active cores > > 34 * 100.0 = 3400.0 MHz max turbo 3 active cores > > 34 * 100.0 = 3400.0 MHz max turbo 2 active cores > > 36 * 100.0 = 3600.0 MHz max turbo 1 active cores > > cpu0: MSR_CONFIG_TDP_NOMINAL: 0x000d (base_ratio=13) > > cpu0: MSR_CONFIG_TDP_LEVEL_1: 0x0006001c (PKG_MIN_PWR_LVL1=0 > > PKG_MAX_PWR_LVL1=0 LVL1_RATIO=6 PKG_TDP_LVL1=28) > > cpu0: MSR_CONFIG_TDP_LEVEL_2: 0x00100038 (PKG_MIN_PWR_LVL2=0 > > PKG_MAX_PWR_LVL2=0 LVL2_RATIO=16 PKG_TDP_LVL2=56) > > cpu0: MSR_CONFIG_TDP_CONTROL: 0x ( lock=0) > > cpu0: MSR_TURBO_ACTIVATION_RATIO: 0x000c > > (MAX_NON_TURBO_RATIO=12 lock=0) > > cpu0: MSR_PKG_CST_CONFIG_CONTROL: 0x1e008008 (UNdemote-C3, > > UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=8: > > unlimited) > > cpu0: POLL: CPUIDLE CORE POLL IDLE > > cpu0: C1: MWAIT 0x00 > > cpu0: C1E: MWAIT 0x01 > > cpu0: C3: MWAIT 0x10 > > cpu0: C6: MWAIT 0x20 > > cpu0: C7s: MWAIT 0x33 > > cpu0: C8: MWAIT 0x40 > > cpu0: C9: MWAIT 0x50 > > cpu0: C10: MWAIT 0x60 > > cpu0: cpufreq driver: intel_pstate > > cpu0: cpufreq governor: powersave > > cpufreq intel_pstate no_turbo: 0 > > cpu0: MSR_MISC_FEATURE_CONTROL: 0x (L2-Prefetch L2- > > Prefetch-pair L1-Prefetch L1-IP-Prefetch) > > cpu0: MSR_PM_ENABLE: 0x0001 (HWP) > > cpu0: MSR_HWP_CAPABILITIES: 0x01060d24 (high 36 guar 13 eff 6 low > > 1) > > cpu0: MSR_HWP_REQUEST: 0x80002404 (min 4 max 36 des 0 epp 0x80 > > window 0x0 pkg 0x0) > > cpu0: MSR_HWP_INTERRUPT: 0x (Dis_Guaranteed_Perf_Change, > > Dis_Excursion_Min) > > cpu0: MSR_HWP_STATUS: 0x (No-Guaranteed_Perf_Change, No- > > Excursion_Min) > > cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0006 (balanced) > > cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.61 > > Joules, 0.000977 sec.) > > cpu0: MSR_PKG_POWER_INFO: 0x0024 (4 W TDP, RAPL 0 - 0 W, > > 0.00 sec.) > > cpu0: MSR_PKG_POWER_LIMIT: 0x420078009c8048 (UNlocked) > > cpu0: PKG Limit #1: ENabled (9.00 Watts, 24.00 sec, clamp > > DISabled) > > cpu0: PKG Limit #2: DISabled (15.00 Watts, 0.002441* sec, clamp > > DISabled) > > cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de (UNlocked) > > cpu0: DRAM Limit: DISabled (0.00 Watts, 0.000977 sec, clamp > > DISabled) > > cpu0: MSR_PP0_POLICY: 0 > > cpu0: MSR_PP0_POWER_LIMIT: 0x (UNlocked) > > cpu0: Cores Limit: DISabled (0.00 Watts, 0.000977 sec, clamp > > DISabled) > > cpu0: MSR_PP1_POLICY: 0 > > cpu0: MSR_PP1_POWER_LIMIT: 0x (UNlocked) > > cpu0: GFX Limit: DISabled (0.00 Watts, 0.000977 sec, clamp > > DISabled) > > cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x0a640080 (100 C) > > cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88380802 (44 C) > > cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x0003 (100 C, 100 C) > > cpu0: MSR_PKGC3_IRTL: 0x884e (valid, 79872 ns) > > cpu0: MSR_PKGC6_IRTL: 0x8876 (valid, 120832 ns) > > cpu0: MSR_PKGC7_IRTL: 0x8894 (valid, 151552 ns) > > cpu0: MSR_PKGC8_IRTL: 0x88fa (valid, 2560
issues with suspend on Dell XPS 13 2-in-1
Hi All, I have a Dell XPS 13 2-in-1 (9365) that when I supend gets warm and has much shorter than expected battery life, it is about the same as if the laptop just runs. I am currently running Fedora 28 with 4.16.2 kernel. My laptop has NVMe for storage and is configured for AHCI mode in the bios. powertop by default shows >> Bad VM writeback timeout Bad NMI watchdog should be turned off Bad Autosuspend for unknown USB device 1-7 (138a:0091) Bad Runtime PM for I2C Adapter i2c-0 (i915 gmbus dpc) Bad Runtime PM for I2C Adapter i2c-1 (i915 gmbus dpb) Bad Runtime PM for I2C Adapter i2c-2 (i915 gmbus dpd) Bad Runtime PM for PCI Device Intel Corporation Wireless 8265 / 8275 Bad Runtime PM for PCI Device Intel Corporation Device 590c Bad Runtime PM for PCI Device Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader Bad Runtime PM for PCI Device Intel Corporation Device 9d3d Bad Runtime PM for PCI Device Sandisk Corp WD Black NVMe SSD Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PCI Express Root Port #9 Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP Thermal subsystem Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PMC Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP HD Audio Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PCI Express Root Port #1 Bad Runtime PM for PCI Device Intel Corporation Device 9d4b Bad Runtime PM for PCI Device Intel Corporation Xeon E3- 1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem Bad Runtime PM for PCI Device Intel Corporation Sunrise Point-LP Integrated Sensor Hub Bad Runtime PM for PCI Device Intel Corporation Device 591e Good Bluetooth device interface status Good Enable Audio codec power management Good Runtime PM for I2C Adapter i2c-8 (Synopsys DesignWare I2C adapter) Good Autosuspend for USB device Integrated_Webcam_HD [CNFGE16N092020028362] Good Autosuspend for USB device xHCI Host Controller [usb1] Good Autosuspend for USB device xHCI Host Controller [usb2] Good Runtime PM for I2C Adapter i2c-7 (SMBus I801 adapter at efa0) Good Autosuspend for unknown USB device 1-2 (8087:0a2b) Good Runtime PM for I2C Adapter i2c-6 (Synopsys DesignWare I2C adapter) Good I2C Device i2c-DLL077A:01 has no runtime power management Good I2C Device i2c-WCOM482F:00 has no runtime power management Good Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PCI Express Root Port #10 Good Runtime PM for PCI Device Intel Corporation Sunrise Point-LP CSME HECI #1 Good Runtime PM for PCI Device Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 Good Runtime PM for PCI Device Intel Corporation Sunrise Point-LP SMBus Good Runtime PM for PCI Device Intel Corporation Sunrise Point-LP PCI Express Root Port #5 Good Runtime PM for PCI Device Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 Good Wake-on-lan status for device virbr0-nic Good Wake-on-lan status for device virbr0 Good Wake-on-lan status for device wlp60s0 Regards Dennis
Re: [PATCH 00/36] AArch64 Linux kernel port
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters escribió:
> On 07/17/2012 06:35 PM, Joe Perches wrote:
> > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> >
> >> The uname will still report
> >> "aarch64" to match the compiler triplet and also avoid confusion of
> >> existing 32-bit ARM scripts that simply check for "arm*" in the
> >> machine name.
that means that the yum base arch will need to be aarch64 and the arch
used in rpm will be aarch64 also. its throwing something weird and
confusing right in the face of users. I urge you to change it all to
arm64 just changing the directory in the kernel is pointless as it still
exposes all the weirdness of the name to users and will result in a
large amount of education and a constant stream of the same question
"Where do i find the arm64 bits?" until such time as the users learn
that arm64 is aarch64. All the tooling uses "uname -m" to determine the
package architecture.
The triplet that fedora will use will be preferred
arm64-redhat-linux-gnu or aarch64-redhat-linux-gnu
but again aarch64 will propogate to a lot of highly visible places
where it will just cause undue confusion. adding a extra check for
arm64* before arm* if that is what people are using will not be hard to
do.
> > The compiler triplet seems trivial to change.
> >
> > The other bit is a relatively weak argument as the 32bit arm
> > scripts can be changed or fixed likely just as easily.
>
> There's a surprising amount of assumption out there around what arm*
> means (or doing wildcard matches liberally). I'm glad (from the point
> of view of a distribution bootstrap) that we don't have to worry
> about that aspect of getting AArch64 support up and running. The
> directory name is just that - a name - and unimportant. I like
> aarch64 from the point of view of distinguishing "this is not ARM,
> no, it's not just an extension, and no it's not just two numbers
> different or wider regs", but it seems fairly inevitable that it's
> going to be arch/arm64. The main thing is that we understand this
> isn't like i686->x86_64.
autoconf etc checks for " arm-* | armbe-* | armle-* | armeb-* |
armv*-* " arm64-* will not match the existing regexs in common
use. configure scripts will need rebuilding regardless of if its
aarch64 or arm64 to me the argument that arm64 will catch existing
scripts is extremely weak. especially when the first target is really
almost completely new for arm in the server market.
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAlAG1dMACgkQkSxm47BaWfdzRQCfUdBHeLoDDC2yJTOxdMP0k0ej
GcMAoKoRXG6d7xOvhPDbh3p4J8lKHYpb
=KXum
-END PGP SIGNATURE-
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 00/36] AArch64 Linux kernel port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Tue, 10 Jul 2012 11:10:18 +0100 Catalin Marinas escribió: > On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote: > > * Arnd Bergmann wrote: > > > On Saturday 07 July 2012, Olof Johansson wrote: > > > > > ARM introduced AArch64 as part of the ARMv8 architecture > > > > > > > > With the risk of bikeshedding here, but I find the name > > > > awkward. How about just naming the arch port arm64 instead? > > > > It's considerably more descriptive in the context of the > > > > kernel. For reference, we didn't name ppc64, nor powerpc, > > > > after what the IBM/power.org marketing people were currently > > > > calling the architecture at the time either. > > > > > > I agree the name sucks, [...] > > > > So why not change it now, when it only bothers a few dozen > > people and it is only present in 36 patches? Why go full steam > > ahead to annoy thousands of people with it and why spread the > > naming madness to thousands of commits? > > Changing the arch/ dir name is easy at this point. My preference is > for consistency with the official name (that cannot be changed) and > the gcc triplet. I also don't think it annoys thousands of people, > most don't really care. The few reactions I've seen is pretty much > because people were expecting arm64 and it came as something else. > > But I'll make a decision on this before the next version of the > series. > > > > [...] This also includes the rpm and dpkg architecture names, > > > and the string returned by the uname syscall. If everything > > > else is aarch64, we should use that in the kernel directory > > > too, but if everyone calls it arm64 anyway, we should probably > > > use that name for as many things as possible. > > > > Yeah. > > What are Red Hat's plans for the AArh64 rpm architecture name? the rpm arch will be the output of uname -m As i've said previously I personally prefer arm64 I think it will be better for users but they will learn if it ends up being aarch64. if uname -m is arm64 we will have foo-1.1-1.arm64.rpm if uname -m ends up as aarch64 we will have foo-1.1-1.aarch64.rpm Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/8XewACgkQkSxm47BaWfe/xwCgqq9ctMj9VG6zruJtmLDzrRZM Ew8AoJRACBzQCLHLkoSveQ+2XoIrw1rY =e8W0 -END PGP SIGNATURE-
Re: [PATCH 00/36] AArch64 Linux kernel port
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 08 Jul 2012 14:31:05 -0400
Jon Masters wrote:
> On 07/08/2012 03:54 AM, Jon Masters wrote:
>
> > In our bikeshedding conversations pondering future Fedora support,
> > we've pretty much settled on the aarch64 name now, and the hope is
> > that we can also avoid providing 32-bit compatibility (multi-arch)
> > by relying on virtualized guests for any 32-bit story. If that
> > holds, we have some flexibility to e.g. go for 64K page size, etc.
> > if we want.
>
> Let me rephrase that to avoid missunderstanding. I am the strongest
> advocate of the "aarch64" name on our end. Others disagreed with that,
> but when the tooling, kernel, and other stuff settled on the same
> uniform name, it was my understanding that this was de facto settled.
> However, it would be wrong to say there are not dissenting viewpoints.
>
> My biggest fear here, however, is that we end up bikeshedding this to
> death, and we then have some use of one name, some of "arm64", and
> distros failing to agree on things like the correct triplet to use for
> the new architecture (we had some issues with this before). So, if
> we're going to argue over the name and make changes, let's do it now.
> There seems to be no value in the toolchain using one name, which is
> already upstream, and the kernel using another name.
>
> Jon.
I agree that we should be consistent between the tools and kernel.
triplets will always be different between distros. I think that is a
given. I personally don't like the name AArch64 I think that the Arch
is redundant and that the A is way to vague. is it Alpha? ARM? AMD?
armada-xp? Athlon? ? Yum today supports arm64 i do think that the distro
users at first will expect arm64 and go looking for the bits under
patches with arm64 in them. with education they will learn and it will
become second nature but that will take time.
I know that the architecture really is new but thats not really clear
by adding AArch32 into the mix to represent 32 bit arm as ARM has done
or by calling it armv8. There is enough way to confuse them already why
confuse things more by adding yet another variable that is AArch64.
- From my and most of the other Fedora developers that i've discussed it
with its more like reluctant acceptance of AArch64 than thinking is a
good idea.
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk/6CJkACgkQkSxm47BaWfdT2QCdFf7lgiy2EoLhxIsPJ3L6N8UI
ILsAn2V+M2xX0vHhsAiL7hu5UL1vHn2Y
=OEuo
-END PGP SIGNATURE-
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ zÚ&j:+v¨¾«êçzZ+Ê+zf£¢·h§~Ûiÿûàz¹ ®w¥¢¸?¨èÚ&¢)ߢfù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
Re: 2.6.19 (current from git) on SPARC64: Can't mount /
Once upon a time Sunday 17 December 2006 9:20 pm, Adrian Bunk wrote: > On Wed, Dec 13, 2006 at 03:56:46PM -0300, Horst H. von Brand wrote: > > I've been running kernel du jour straight from git on my SPARC Ultra 1 > > for some time now on Aurora Corona (Fedora relative, development branch). > > For a few days now 2.6.19 panics on boot, it can't mount /. 2.6.19 worked > > fine, as does 2.6.19.1 (Aurora changed gcc, mkinitrd, ... in between, so > > I had to rebuild a kernel to check if the problem lay elsewhere). > > Unpacking the initrds for 2.6.19 and 2.6.19.1 shows the same (nash > > script) /init and the same modules in both (ext3 + jbd, scsi_mod, sd_mod, > > esp, others). > > > > I'm stumped. Any clue? not 100% sure here. Check the size of the initrd. kinda sounds like an issue that hit rawhide last week that needed a new mkinitrd. if its smaller grab the srpm from the Fedora Development tree for mkinitrd and rebuild it. then recreate your initrd and see if that works. Dennis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
