arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
Subsystems (4)
cover arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
The Khadas VIM4 has needed clk_ignore_unused to boot reliably. Without it the board hangs at random, loses storage and corrupts memory, and the failures move around from boot to boot.
Six of the SoC's PWM outputs drive the board's voltage regulators: the always-on domain, both CPU clusters, the GPU, the NPU and the DRAM. None of them were described, so Linux saw the outputs as unused and switched them off about a second into boot. The regulators then drifted away from the levels the bootloader had set, which is where the corruption and the random hangs came from.
Thanks to Chuan Liu from Amlogic for helping me indetify which clocks are critical.
Separately, four clocks feed the bus that carries data between the peripherals and memory. Nothing claims those either, and switching them off leaves any device that starts a transfer afterwards stuck. The SD card comes up about two seconds into boot, so it was the visible victim.
Two of the patches are pin group fixes. The description named groups that do not exist in the pinctrl driver, so anything referencing them refused to probe. That is what the supplies patch needs in order to work, and it had a second effect worth mentioning: the failing probe left one device unbound, which kept the clock controller's sync_state() deferred forever and quietly stopped every peripheral clock from ever being switched off. The board looked healthy for entirely the wrong reason.
Tested on a VIM4 booting from SD with no clk_ignore_unused: 74 clocks are still switched off, but the card enumerates and the root filesystem mounts and memtest runs clean over 512 MiB.
Thread about these issues in Vim4:
https://lore.kernel.org/linux-clk/[email protected]/
Lucas Tanure (4):
clk: meson: t7: keep the memory fabric clocks running
arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies
arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM
.../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 110 +++++++++++++++++- arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 44 ++++++- drivers/clk/meson/t7-peripherals.c | 13 ++- 3 files changed, 156 insertions(+), 11 deletions(-)
Signature · 1 line
2.55.0
PATCH 1/4 clk: meson: t7: keep the memory fabric clocks running
Four clocks feed the bus that moves data between the peripherals and memory. Nothing in Linux claims them, so they were switched off shortly after boot, and any device that started a transfer after that point simply stopped. The SD card, which comes up about two seconds in, never finished reading its identification.
There is no device these clocks belong to, so mark them as always needed.
--- drivers/clk/meson/t7-peripherals.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/clk/meson/t7-peripherals.c +9 -4
@@ -945,11 +945,16 @@ static T7_SYS_PCLK(sys_aucpu, SYS_CLK_EN0_REG0, 14, 0); static T7_SYS_PCLK(sys_cec, SYS_CLK_EN0_REG0, 16, 0); static T7_SYS_PCLK(sys_gdc, SYS_CLK_EN0_REG0, 17, 0); static T7_SYS_PCLK(sys_deswarp, SYS_CLK_EN0_REG0, 18, 0); -static T7_SYS_PCLK(sys_ampipe_nand, SYS_CLK_EN0_REG0, 19, 0); +/* +* NOTE: sys_ampipe_nand and sys_am2axi0..2 provide the clock to the AXI bus +* used for DMA between the peripherals and the DRAM. After the clocks are +* disabled, a device that starts a transfer cannot complete it. +*/ +static T7_SYS_PCLK(sys_ampipe_nand, SYS_CLK_EN0_REG0, 19, CLK_IS_CRITICAL); static T7_SYS_PCLK(sys_ampipe_eth, SYS_CLK_EN0_REG0, 20, 0); -static T7_SYS_PCLK(sys_am2axi0, SYS_CLK_EN0_REG0, 21, 0); -static T7_SYS_PCLK(sys_am2axi1, SYS_CLK_EN0_REG0, 22, 0); -static T7_SYS_PCLK(sys_am2axi2, SYS_CLK_EN0_REG0, 23, 0); +static T7_SYS_PCLK(sys_am2axi0, SYS_CLK_EN0_REG0, 21, CLK_IS_CRITICAL); +static T7_SYS_PCLK(sys_am2axi1, SYS_CLK_EN0_REG0, 22, CLK_IS_CRITICAL); +static T7_SYS_PCLK(sys_am2axi2, SYS_CLK_EN0_REG0, 23, CLK_IS_CRITICAL); static T7_SYS_PCLK(sys_sd_emmc_a, SYS_CLK_EN0_REG0, 24, 0); static T7_SYS_PCLK(sys_sd_emmc_b, SYS_CLK_EN0_REG0, 25, 0); static T7_SYS_PCLK(sys_sd_emmc_c, SYS_CLK_EN0_REG0, 26, 0);
Signature · 1 line
2.55.0
PATCH 2/4 arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
In reply to Lucas TanureTwo of the PWM outputs can each appear on more than one pin, but the description named a single group that does not exist, so anything using it refused to start.
Name the real groups instead, one entry per pin, the same way the other multi-pin PWM output is already described.
--- arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 32 ++++++++++++++++++--- 1 file changed, 28 insertions(+), 4 deletions(-)
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi +28 -4
@@ -458,9 +458,25 @@ mux { }; }; - pwm_ao_g_pins: pwm-ao-g { + pwm_ao_g_d11_pins: pwm-ao-g-d11 { mux { - groups = "pwm_ao_g"; + groups = "pwm_ao_g_d11"; + function = "pwm_ao_g"; + bias-disable; + }; + }; + + pwm_ao_g_d7_pins: pwm-ao-g-d7 { + mux { + groups = "pwm_ao_g_d7"; + function = "pwm_ao_g"; + bias-disable; + }; + }; + + pwm_ao_g_e_pins: pwm-ao-g-e { + mux { + groups = "pwm_ao_g_e"; function = "pwm_ao_g"; bias-disable; };
@@ -474,9 +490,17 @@ mux { }; }; - pwm_ao_h_pins: pwm-ao-h { + pwm_ao_h_d5_pins: pwm-ao-h-d5 { + mux { + groups = "pwm_ao_h_d5"; + function = "pwm_ao_h"; + bias-disable; + }; + }; + + pwm_ao_h_d10_pins: pwm-ao-h-d10 { mux { - groups = "pwm_ao_h"; + groups = "pwm_ao_h_d10"; function = "pwm_ao_h"; bias-disable; };
Signature · 1 line
2.55.0
Re: [PATCH 2/4] arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
Quoted 56 lines · Lucas Tanure
Two of the PWM outputs can each appear on more than one pin, but the description named a single group that does not exist, so anything using it refused to start.
Name the real groups instead, one entry per pin, the same way the other multi-pin PWM output is already described.
Fixes 2a2a7b9701a7 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes")Assisted-by Claude:claude-opus-5Signed-off-by Lucas Tanure <[email protected]>--- arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 32 ++++++++++++++++++--- 1 file changed, 28 insertions(+), 4 deletions(-)arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi +23
-3@@ -458,9 +458,25 @@ mux { }; }; - pwm_ao_g_pins: pwm-ao-g { + pwm_ao_g_d11_pins: pwm-ao-g-d11 { mux { - groups = "pwm_ao_g"; + groups = "pwm_ao_g_d11"; + function = "pwm_ao_g"; + bias-disable; + }; + }; + + pwm_ao_g_d7_pins: pwm-ao-g-d7 { + mux { + groups = "pwm_ao_g_d7"; + function = "pwm_ao_g"; + bias-disable; + }; + }; + + pwm_ao_g_e_pins: pwm-ao-g-e { + mux { + groups = "pwm_ao_g_e"; function = "pwm_ao_g"; bias-disable; };@@ -474,9 +490,17 @@ mux { }; }; - pwm_ao_h_pins: pwm-ao-h { + pwm_ao_h_d5_pins: pwm-ao-h-d5 { + mux { + groups = "pwm_ao_h_d5"; + function = "pwm_ao_h"; + bias-disable;
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi mux { · line 506
Quoted 10 lines
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi +5
-1+ }; + }; + + pwm_ao_h_d10_pins: pwm-ao-h-d10 { mux { - groups = "pwm_ao_h"; + groups = "pwm_ao_h_d10"; function = "pwm_ao_h"; bias-disable; };
Thanks,
Neil
PATCH 3/4 arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies
In reply to Lucas TanureThe board powers its two CPU clusters, the GPU, the NPU, the memory and the always-on domain from regulators steered by PWM outputs. None of them were described, so Linux treated those outputs as unused and switched them off part way through boot. The supplies then drifted away from the levels the bootloader had set, which showed up as random hangs and memory corruption.
Describe each supply so it has an owner and is left alone.
The voltage ranges are read off the feedback networks on the board schematic. VDDNPU is deliberately not the range in Amlogic's own device tree: this board fits a different feedback resistor, which puts it about 40mV higher at both ends.
--- .../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 110 +++++++++++++++++- 1 file changed, 109 insertions(+), 1 deletion(-)
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts +109 -1
@@ -104,6 +104,66 @@ vcc5v0_usb: regulator-vcc-usb { enable-active-high; }; + vdd_ddr: regulator-vddddr { + /* + * SY8003ADFC Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDDDR"; + regulator-min-microvolt = <690000>; + regulator-max-microvolt = <890000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_gh 0 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vdd_ee: regulator-vddee { + /* + * MP8756GD Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDEE"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <922000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ab 0 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vdd_gpu: regulator-vddgpu { + /* + * SY8003ADFC Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDGPU"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <922000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ef 0 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vdd_npu: regulator-vddnpu { + /* + * SY8003ADFC Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDNPU"; + regulator-min-microvolt = <733000>; + regulator-max-microvolt = <933000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ef 1 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + vddao_1v8: regulator-vddao-1v8 { compatible = "regulator-fixed"; regulator-name = "VDDAO_1V8";
@@ -122,6 +182,36 @@ vddao_3v3: regulator-vddao-3v3 { regulator-always-on; }; + vddcpu_a: regulator-vddcpu-a { + /* + * MP8756GD Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDCPU_A"; + regulator-min-microvolt = <689000>; + regulator-max-microvolt = <1049000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_cd 1 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vddcpu_b: regulator-vddcpu-b { + /* + * MP8756GD Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDCPU_B"; + regulator-min-microvolt = <689000>; + regulator-max-microvolt = <1049000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ab 1 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + vddio_1v8: regulator-vddio-1v8 { compatible = "regulator-fixed"; regulator-name = "VDDIO_1V8";
@@ -172,9 +262,27 @@ &pwm_ab { pinctrl-names = "default"; }; +&pwm_ao_ab { + status = "okay"; + pinctrl-0 = <&pwm_ao_a_pins>, <&pwm_ao_b_pins>; + pinctrl-names = "default"; +}; + &pwm_ao_cd { status = "okay"; - pinctrl-0 = <&pwm_ao_c_d_pins>; + pinctrl-0 = <&pwm_ao_c_d_pins>, <&pwm_ao_d_pins>; + pinctrl-names = "default"; +}; + +&pwm_ao_ef { + status = "okay"; + pinctrl-0 = <&pwm_ao_e_pins>, <&pwm_ao_f_pins>; + pinctrl-names = "default"; +}; + +&pwm_ao_gh { + status = "okay"; + pinctrl-0 = <&pwm_ao_g_e_pins>; pinctrl-names = "default"; };
Signature · 1 line
2.55.0
Re: [PATCH 3/4] arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies
Quoted 148 lines · Lucas Tanure
The board powers its two CPU clusters, the GPU, the NPU, the memory and the always-on domain from regulators steered by PWM outputs. None of them were described, so Linux treated those outputs as unused and switched them off part way through boot. The supplies then drifted away from the levels the bootloader had set, which showed up as random hangs and memory corruption.
Describe each supply so it has an owner and is left alone.
The voltage ranges are read off the feedback networks on the board schematic. VDDNPU is deliberately not the range in Amlogic's own device tree: this board fits a different feedback resistor, which puts it about 40mV higher at both ends.
Fixes 8c45bf9ae4ef ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators")Assisted-by Claude:claude-opus-5Signed-off-by Lucas Tanure <[email protected]>--- .../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 110 +++++++++++++++++- 1 file changed, 109 insertions(+), 1 deletion(-)arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts +102
-1@@ -104,6 +104,66 @@ vcc5v0_usb: regulator-vcc-usb { enable-active-high; }; + vdd_ddr: regulator-vddddr { + /* + * SY8003ADFC Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDDDR"; + regulator-min-microvolt = <690000>; + regulator-max-microvolt = <890000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_gh 0 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vdd_ee: regulator-vddee { + /* + * MP8756GD Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDEE"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <922000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ab 0 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vdd_gpu: regulator-vddgpu { + /* + * SY8003ADFC Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDGPU"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <922000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ef 0 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vdd_npu: regulator-vddnpu { + /* + * SY8003ADFC Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDNPU"; + regulator-min-microvolt = <733000>; + regulator-max-microvolt = <933000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ef 1 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + vddao_1v8: regulator-vddao-1v8 { compatible = "regulator-fixed"; regulator-name = "VDDAO_1V8";@@ -122,6 +182,36 @@ vddao_3v3: regulator-vddao-3v3 { regulator-always-on; }; + vddcpu_a: regulator-vddcpu-a { + /* + * MP8756GD Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDCPU_A"; + regulator-min-microvolt = <689000>; + regulator-max-microvolt = <1049000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_cd 1 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + + vddcpu_b: regulator-vddcpu-b { + /* + * MP8756GD Regulator. + */ + compatible = "pwm-regulator"; + regulator-name = "VDDCPU_B"; + regulator-min-microvolt = <689000>; + regulator-max-microvolt = <1049000>; + pwm-supply = <&dc_in>; + pwms = <&pwm_ao_ab 1 1500 0>; + pwm-dutycycle-range = <100 0>; + regulator-boot-on; + regulator-always-on; + }; + vddio_1v8: regulator-vddio-1v8 { compatible = "regulator-fixed"; regulator-name = "VDDIO_1V8";@@ -172,9 +262,27 @@ &pwm_ab { pinctrl-names = "default"; }; +&pwm_ao_ab { + status = "okay"; + pinctrl-0 = <&pwm_ao_a_pins>, <&pwm_ao_b_pins>; + pinctrl-names = "default"; +}; + &pwm_ao_cd { status = "okay"; - pinctrl-0 = <&pwm_ao_c_d_pins>; + pinctrl-0 = <&pwm_ao_c_d_pins>, <&pwm_ao_d_pins>; + pinctrl-names = "default"; +}; + +&pwm_ao_ef { + status = "okay";
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts &pwm_ab { · line 288
Quoted 10 lines
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts +7
-0+ pinctrl-0 = <&pwm_ao_e_pins>, <&pwm_ao_f_pins>; + pinctrl-names = "default"; +}; + +&pwm_ao_gh { + status = "okay"; + pinctrl-0 = <&pwm_ao_g_e_pins>; pinctrl-names = "default"; };
Thanks,
Neil
PATCH 4/4 arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM
In reply to Lucas TanureThe vsync PWM output can appear on either of two pins, but the description named a single group that does not exist, so anything using it would refuse to start.
Name the real groups instead, one entry per pin. No board describes this output yet, so nothing changes today.
--- arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi +10 -2
@@ -546,9 +546,17 @@ mux { }; }; - pwm_vs_pins: pwm-vs { + pwm_vs_y_pins: pwm-vs-y { mux { - groups = "pwm_vs"; + groups = "pwm_vs_y"; + function = "pwm_vs"; + bias-disable; + }; + }; + + pwm_vs_h_pins: pwm-vs-h { + mux { + groups = "pwm_vs_h"; function = "pwm_vs"; bias-disable; };
Signature · 1 line
2.55.0
Re: [PATCH 4/4] arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM
Quoted 28 lines · Lucas Tanure
The vsync PWM output can appear on either of two pins, but the description named a single group that does not exist, so anything using it would refuse to start.
Name the real groups instead, one entry per pin. No board describes this output yet, so nothing changes today.
Fixes 2a2a7b9701a7 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes")Assisted-by Claude:claude-opus-5Signed-off-by Lucas Tanure <[email protected]>--- arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi +3
-2@@ -546,9 +546,17 @@ mux { }; }; - pwm_vs_pins: pwm-vs { + pwm_vs_y_pins: pwm-vs-y { mux { - groups = "pwm_vs"; + groups = "pwm_vs_y"; + function = "pwm_vs";
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi mux { · line 562
Quoted 10 lines
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi +7
-0+ bias-disable; + }; + }; + + pwm_vs_h_pins: pwm-vs-h { + mux { + groups = "pwm_vs_h"; function = "pwm_vs"; bias-disable; };
Thanks,
Neil
Re: (subset) [PATCH 0/4] arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
In reply to Lucas TanureApplied to clk-meson (clk-meson-next), thanks!
[1/4] clk: meson: t7: keep the memory fabric clocks running
https://github.com/BayLibre/clk-meson/commit/43e1705ecab9
Best regards,
--
Jerome
Re: (subset) [PATCH 0/4] arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
In reply to Lucas TanureHi,
Quoted 13 lines · Lucas Tanure
The Khadas VIM4 has needed
clk_ignore_unusedto boot reliably. Without it the board hangs at random, loses storage and corrupts memory, and the failures move around from boot to boot.Six of the SoC's PWM outputs drive the board's voltage regulators: the always-on domain, both CPU clusters, the GPU, the NPU and the DRAM. None of them were described, so Linux saw the outputs as unused and switched them off about a second into boot. The regulators then drifted away from the levels the bootloader had set, which is where the corruption and the random hangs came from.
Thanks to Chuan Liu from Amlogic for helping me indetify which clocks are critical.
Quoted 1 line
[...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/fixes)
[2/4] arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
https://git.kernel.org/amlogic/c/ae7be5c58a819259e5eb98a3abfa60842478f2ae [3/4] arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies https://git.kernel.org/amlogic/c/1e5a53bd16ac501e68463e84023d1bff543cc696 [4/4] arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM https://git.kernel.org/amlogic/c/406292fd75f95aa3010fec95b5beb5a8b7e3ba3a
These changes has been applied on the intermediate git tree [1].
The v7.3/fixes branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Signature · 1 line
Neil
Re: (subset) [PATCH 0/4] arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
Quoted 45 lines · Neil Armstrong
Hi,
Quoted 13 lines · Lucas Tanure
The Khadas VIM4 has needed
clk_ignore_unusedto boot reliably. Without it the board hangs at random, loses storage and corrupts memory, and the failures move around from boot to boot.Six of the SoC's PWM outputs drive the board's voltage regulators: the always-on domain, both CPU clusters, the GPU, the NPU and the DRAM. None of them were described, so Linux saw the outputs as unused and switched them off about a second into boot. The regulators then drifted away from the levels the bootloader had set, which is where the corruption and the random hangs came from.
Thanks to Chuan Liu from Amlogic for helping me indetify which clocks are critical.Quoted 1 line
[...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/fixes)
[2/4] arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
https://git.kernel.org/amlogic/c/ae7be5c58a819259e5eb98a3abfa60842478f2ae [3/4] arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies https://git.kernel.org/amlogic/c/1e5a53bd16ac501e68463e84023d1bff543cc696 [4/4] arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM https://git.kernel.org/amlogic/c/406292fd75f95aa3010fec95b5beb5a8b7e3ba3aThese changes has been applied on the intermediate git tree [1].
The v7.3/fixes branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset.
Quoted 7 lines
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git--
Neil
Hi,
Please don't take this. I will submit a better version. sys_ampipe_nand should not be critical.
Thanks,
Lucas
Jerome Brunet
maintainerRe: (subset) [PATCH 0/4] arm64: amlogic: t7: describe the VIM4 supplies and keep the fabric clocks running
Quoted 51 lines · Lucas Tanure
Quoted 49 lines · Neil Armstrong
Hi,
Quoted 13 lines · Lucas Tanure
The Khadas VIM4 has needed
clk_ignore_unusedto boot reliably. Without it the board hangs at random, loses storage and corrupts memory, and the failures move around from boot to boot.Six of the SoC's PWM outputs drive the board's voltage regulators: the always-on domain, both CPU clusters, the GPU, the NPU and the DRAM. None of them were described, so Linux saw the outputs as unused and switched them off about a second into boot. The regulators then drifted away from the levels the bootloader had set, which is where the corruption and the random hangs came from.
Thanks to Chuan Liu from Amlogic for helping me indetify which clocks are critical.Quoted 1 line
[...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/fixes)
[2/4] arm64: dts: amlogic: t7: fix the pin groups of two PWM outputs
https://git.kernel.org/amlogic/c/ae7be5c58a819259e5eb98a3abfa60842478f2ae [3/4] arm64: dts: amlogic: t7: khadas-vim4: add the PWM-driven supplies https://git.kernel.org/amlogic/c/1e5a53bd16ac501e68463e84023d1bff543cc696 [4/4] arm64: dts: amlogic: t7: fix the pin groups of the vsync PWM https://git.kernel.org/amlogic/c/406292fd75f95aa3010fec95b5beb5a8b7e3ba3aThese changes has been applied on the intermediate git tree [1].
The v7.3/fixes branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Quoted 6 lines
Quoted 3 lines
--
NeilHi,
Please don't take this. I will submit a better version.sys_ampipe_nandshould not be critical.
Please submit a fixup change on top of what you've already sent, with the proper 'Fixes:' tag.
Quoted 3 lines
Thanks,
Lucas
Signature · 1 line
Jerome