* [PATCH 00/13] GS101 Oriole: CMU_PERIC0 support and USI updates
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Add support for PERIC0 clocks. Use them for USI in serial and I2C
configurations. Tested the serial at different baudrates (115200,
1M, 3M) and the I2C with an at24 eeprom, all went fine.
Apart of the DT and defconfig changes, the patch set spans through the tty
and clk subsystems. The expectation is that Krzysztof will apply the whole
series through the Samsung SoC tree. If the tty and clk subsystem
maintainers can give an acked-by or reviewed-by on the relevant patches
that would be most appreciated!
Thanks!
ta
Tudor Ambarus (13):
dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
dt-bindings: clock: google,gs101-clock: add PERIC0 clock management
unit
dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
dt-bindings: serial: samsung: gs101: make reg-io-width required
property
tty: serial: samsung: add gs101 earlycon support
clk: samsung: gs101: add support for cmu_peric0
clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
arm64: dts: exynos: gs101: define USI8 with I2C configuration
arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
arm64: defconfig: sync with savedefconfig
arm64: defconfig: make at24 eeprom builtin
.../bindings/clock/google,gs101-clock.yaml | 25 +-
.../devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
.../bindings/serial/samsung_uart.yaml | 4 +
.../boot/dts/exynos/google/gs101-oriole.dts | 18 +
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 52 +-
arch/arm64/configs/defconfig | 146 ++--
drivers/clk/samsung/clk-gs101.c | 748 ++++++++++++++++--
drivers/tty/serial/samsung_tty.c | 11 +
include/dt-bindings/clock/google,gs101.h | 230 ++++--
9 files changed, 980 insertions(+), 255 deletions(-)
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH 00/13] GS101 Oriole: CMU_PERIC0 support and USI updates
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Add support for PERIC0 clocks. Use them for USI in serial and I2C
configurations. Tested the serial at different baudrates (115200,
1M, 3M) and the I2C with an at24 eeprom, all went fine.
Apart of the DT and defconfig changes, the patch set spans through the tty
and clk subsystems. The expectation is that Krzysztof will apply the whole
series through the Samsung SoC tree. If the tty and clk subsystem
maintainers can give an acked-by or reviewed-by on the relevant patches
that would be most appreciated!
Thanks!
ta
Tudor Ambarus (13):
dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
dt-bindings: clock: google,gs101-clock: add PERIC0 clock management
unit
dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
dt-bindings: serial: samsung: gs101: make reg-io-width required
property
tty: serial: samsung: add gs101 earlycon support
clk: samsung: gs101: add support for cmu_peric0
clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
arm64: dts: exynos: gs101: define USI8 with I2C configuration
arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
arm64: defconfig: sync with savedefconfig
arm64: defconfig: make at24 eeprom builtin
.../bindings/clock/google,gs101-clock.yaml | 25 +-
.../devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
.../bindings/serial/samsung_uart.yaml | 4 +
.../boot/dts/exynos/google/gs101-oriole.dts | 18 +
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 52 +-
arch/arm64/configs/defconfig | 146 ++--
drivers/clk/samsung/clk-gs101.c | 748 ++++++++++++++++--
drivers/tty/serial/samsung_tty.c | 11 +
include/dt-bindings/clock/google,gs101.h | 230 ++++--
9 files changed, 980 insertions(+), 255 deletions(-)
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
The gs101 clock names are derived from the clock register names under
some certain rules. In particular, for the gate clocks the following is
documented and expected in the gs101 clock driver:
Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
The CMU TOP gate clock names missed to include the required "CMU"
differentiator which will cause name collisions with the gate clock names
of other clock units. Fix the TOP gate clock names and include "CMU" in
their name.
Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/clk/samsung/clk-gs101.c | 167 ++++++++++++-----------
include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
2 files changed, 159 insertions(+), 152 deletions(-)
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index a3dda97f5eb9..0964bb11657f 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -17,7 +17,7 @@
#include "clk-exynos-arm64.h"
/* NOTE: Must be equal to the last clock ID increased by one */
-#define CLKS_NR_TOP (CLK_GOUT_TPU_UART + 1)
+#define CLKS_NR_TOP (CLK_GOUT_CMU_TPU_UART + 1)
#define CLKS_NR_APM (CLK_APM_PLL_DIV16_APM + 1)
#define CLKS_NR_MISC (CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
@@ -1259,160 +1259,167 @@ static const struct samsung_fixed_factor_clock cmu_top_ffactor[] __initconst = {
};
static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
- GATE(CLK_GOUT_BUS0_BOOST, "gout_cmu_bus0_boost",
+ GATE(CLK_GOUT_CMU_BUS0_BOOST, "gout_cmu_bus0_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS0_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_BUS1_BOOST, "gout_cmu_bus1_boost",
+ GATE(CLK_GOUT_CMU_BUS1_BOOST, "gout_cmu_bus1_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS1_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_BUS2_BOOST, "gout_cmu_bus2_boost",
+ GATE(CLK_GOUT_CMU_BUS2_BOOST, "gout_cmu_bus2_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS2_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_CORE_BOOST, "gout_cmu_core_boost",
+ GATE(CLK_GOUT_CMU_CORE_BOOST, "gout_cmu_core_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CORE_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
+ GATE(CLK_GOUT_CMU_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL0_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
+ GATE(CLK_GOUT_CMU_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL1_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
+ GATE(CLK_GOUT_CMU_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL2_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_MIF_BOOST, "gout_cmu_mif_boost",
+ GATE(CLK_GOUT_CMU_MIF_BOOST, "gout_cmu_mif_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_MIF_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_MIF_SWITCH, "gout_cmu_mif_switch", "mout_cmu_mif_switch",
- CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
- GATE(CLK_GOUT_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
+ GATE(CLK_GOUT_CMU_MIF_SWITCH, "gout_cmu_mif_switch",
+ "mout_cmu_mif_switch", CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
+ GATE(CLK_GOUT_CMU_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
CLK_CON_GAT_GATE_CLKCMU_BO_BUS, 21, 0, 0),
- GATE(CLK_GOUT_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
+ GATE(CLK_GOUT_CMU_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS, 21, 0, 0),
- GATE(CLK_GOUT_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
+ GATE(CLK_GOUT_CMU_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS, 21, 0, 0),
- GATE(CLK_GOUT_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
+ GATE(CLK_GOUT_CMU_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
+ GATE(CLK_GOUT_CMU_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
+ GATE(CLK_GOUT_CMU_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
+ GATE(CLK_GOUT_CMU_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
+ GATE(CLK_GOUT_CMU_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
+ GATE(CLK_GOUT_CMU_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
+ GATE(CLK_GOUT_CMU_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
+ GATE(CLK_GOUT_CMU_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
+ GATE(CLK_GOUT_CMU_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7, 21, 0, 0),
- GATE(CLK_GOUT_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
+ GATE(CLK_GOUT_CMU_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
+ GATE(CLK_GOUT_CMU_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
CLK_CON_GAT_GATE_CLKCMU_CORE_BUS, 21, 0, 0),
- GATE(CLK_GOUT_CPUCL0_DBG, "gout_cmu_cpucl0_dbg", "mout_cmu_cpucl0_dbg",
- CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS, 21, 0, 0),
- GATE(CLK_GOUT_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
+ GATE(CLK_GOUT_CMU_CPUCL0_DBG, "gout_cmu_cpucl0_dbg",
+ "mout_cmu_cpucl0_dbg", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
"mout_cmu_cpucl0_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
+ GATE(CLK_GOUT_CMU_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
"mout_cmu_cpucl1_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
+ GATE(CLK_GOUT_CMU_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
"mout_cmu_cpucl2_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH,
21, 0, 0),
- GATE(CLK_GOUT_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
+ GATE(CLK_GOUT_CMU_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
- GATE(CLK_GOUT_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
+ GATE(CLK_GOUT_CMU_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
CLK_CON_GAT_GATE_CLKCMU_DISP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
+ GATE(CLK_GOUT_CMU_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
CLK_CON_GAT_GATE_CLKCMU_DNS_BUS, 21, 0, 0),
- GATE(CLK_GOUT_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
+ GATE(CLK_GOUT_CMU_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
CLK_CON_GAT_GATE_CLKCMU_DPU_BUS, 21, 0, 0),
- GATE(CLK_GOUT_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
+ GATE(CLK_GOUT_CMU_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
CLK_CON_GAT_GATE_CLKCMU_EH_BUS, 21, 0, 0),
- GATE(CLK_GOUT_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
+ GATE(CLK_GOUT_CMU_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
CLK_CON_GAT_GATE_CLKCMU_G2D_G2D, 21, 0, 0),
- GATE(CLK_GOUT_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
+ GATE(CLK_GOUT_CMU_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL, 21, 0, 0),
- GATE(CLK_GOUT_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
+ GATE(CLK_GOUT_CMU_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
- GATE(CLK_GOUT_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
+ GATE(CLK_GOUT_CMU_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD, 21, 0, 0),
- GATE(CLK_GOUT_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
+ GATE(CLK_GOUT_CMU_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
CLK_CON_GAT_GATE_CLKCMU_G3D_GLB, 21, 0, 0),
- GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_switch", "mout_cmu_g3d_switch",
- CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH, 21, 0, 0),
- GATE(CLK_GOUT_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
+ GATE(CLK_GOUT_CMU_G3D_SWITCH, "gout_cmu_g3d_switch",
+ "mout_cmu_g3d_switch", CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0, 21, 0, 0),
- GATE(CLK_GOUT_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
+ GATE(CLK_GOUT_CMU_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1, 21, 0, 0),
- GATE(CLK_GOUT_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
+ GATE(CLK_GOUT_CMU_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC, 21, 0, 0),
GATE(CLK_GOUT_CMU_HPM, "gout_cmu_hpm", "mout_cmu_hpm",
CLK_CON_GAT_GATE_CLKCMU_HPM, 21, 0, 0),
- GATE(CLK_GOUT_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
+ GATE(CLK_GOUT_CMU_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS, 21, 0, 0),
- GATE(CLK_GOUT_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc", "mout_cmu_hsi0_dpgtc",
- CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC, 21, 0, 0),
- GATE(CLK_GOUT_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
+ GATE(CLK_GOUT_CMU_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc",
+ "mout_cmu_hsi0_dpgtc", CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
"mout_cmu_hsi0_usb31drd", CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD,
21, 0, 0),
- GATE(CLK_GOUT_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
+ GATE(CLK_GOUT_CMU_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
"mout_cmu_hsi0_usbdpdbg", CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG,
21, 0, 0),
- GATE(CLK_GOUT_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
+ GATE(CLK_GOUT_CMU_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS, 21, 0, 0),
- GATE(CLK_GOUT_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
+ GATE(CLK_GOUT_CMU_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE, 21, 0, 0),
- GATE(CLK_GOUT_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
+ GATE(CLK_GOUT_CMU_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS, 21, 0, 0),
- GATE(CLK_GOUT_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
+ GATE(CLK_GOUT_CMU_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
"mout_cmu_hsi2_mmc_card", CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD,
21, 0, 0),
- GATE(CLK_GOUT_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
+ GATE(CLK_GOUT_CMU_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE, 21, 0, 0),
- GATE(CLK_GOUT_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
+ GATE(CLK_GOUT_CMU_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
"mout_cmu_hsi2_ufs_embd", CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD,
21, 0, 0),
- GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
+ GATE(CLK_GOUT_CMU_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
+ GATE(CLK_GOUT_CMU_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
CLK_CON_GAT_GATE_CLKCMU_ITP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
+ GATE(CLK_GOUT_CMU_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC, 21, 0, 0),
- GATE(CLK_GOUT_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
+ GATE(CLK_GOUT_CMU_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC, 21, 0, 0),
- GATE(CLK_GOUT_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
+ GATE(CLK_GOUT_CMU_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
CLK_CON_GAT_GATE_CLKCMU_MFC_MFC, 21, 0, 0),
- GATE(CLK_GOUT_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
+ GATE(CLK_GOUT_CMU_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP, 21, 0, 0),
- GATE(CLK_GOUT_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
+ GATE(CLK_GOUT_CMU_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
CLK_CON_GAT_GATE_CLKCMU_MISC_BUS, 21, 0, 0),
- GATE(CLK_GOUT_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
+ GATE(CLK_GOUT_CMU_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
CLK_CON_GAT_GATE_CLKCMU_MISC_SSS, 21, 0, 0),
- GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
+ GATE(CLK_GOUT_CMU_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
+ GATE(CLK_GOUT_CMU_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PERIC0_BUS, "gout_cmu_peric0_bus", "mout_cmu_peric0_bus",
- CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
+ GATE(CLK_GOUT_CMU_PERIC0_BUS, "gout_cmu_peric0_bus",
+ "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
- GATE(CLK_GOUT_PERIC1_BUS, "gout_cmu_peric1_bus", "mout_cmu_peric1_bus",
- CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
+ GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
+ "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP, 21, 0, 0),
- GATE(CLK_GOUT_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
+ GATE(CLK_GOUT_CMU_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
CLK_CON_GAT_GATE_CLKCMU_TNR_BUS, 21, 0, 0),
- GATE(CLK_GOUT_TOP_CMUREF, "gout_cmu_top_cmuref", "mout_cmu_top_cmuref",
- CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF, 21, 0, 0),
- GATE(CLK_GOUT_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
+ GATE(CLK_GOUT_CMU_TOP_CMUREF, "gout_cmu_top_cmuref",
+ "mout_cmu_top_cmuref", CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
CLK_CON_GAT_GATE_CLKCMU_TPU_BUS, 21, 0, 0),
- GATE(CLK_GOUT_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
+ GATE(CLK_GOUT_CMU_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
CLK_CON_GAT_GATE_CLKCMU_TPU_TPU, 21, 0, 0),
- GATE(CLK_GOUT_TPU_TPUCTL, "gout_cmu_tpu_tpuctl", "mout_cmu_tpu_tpuctl",
- CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL, 21, 0, 0),
- GATE(CLK_GOUT_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
+ GATE(CLK_GOUT_CMU_TPU_TPUCTL, "gout_cmu_tpu_tpuctl",
+ "mout_cmu_tpu_tpuctl", CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
CLK_CON_GAT_GATE_CLKCMU_TPU_UART, 21, 0, 0),
};
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 9761c0b24e66..21adec22387c 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -166,79 +166,79 @@
#define CLK_DOUT_CMU_SHARED3_DIV2 150
/* CMU_TOP Gates */
-#define CLK_GOUT_BUS0_BOOST 151
-#define CLK_GOUT_BUS1_BOOST 152
-#define CLK_GOUT_BUS2_BOOST 153
-#define CLK_GOUT_CORE_BOOST 154
-#define CLK_GOUT_CPUCL0_BOOST 155
-#define CLK_GOUT_CPUCL1_BOOST 156
-#define CLK_GOUT_CPUCL2_BOOST 157
-#define CLK_GOUT_MIF_BOOST 158
-#define CLK_GOUT_MIF_SWITCH 159
-#define CLK_GOUT_BO_BUS 160
-#define CLK_GOUT_BUS0_BUS 161
-#define CLK_GOUT_BUS1_BUS 162
-#define CLK_GOUT_BUS2_BUS 163
-#define CLK_GOUT_CIS_CLK0 164
-#define CLK_GOUT_CIS_CLK1 165
-#define CLK_GOUT_CIS_CLK2 166
-#define CLK_GOUT_CIS_CLK3 167
-#define CLK_GOUT_CIS_CLK4 168
-#define CLK_GOUT_CIS_CLK5 169
-#define CLK_GOUT_CIS_CLK6 170
-#define CLK_GOUT_CIS_CLK7 171
-#define CLK_GOUT_CMU_BOOST 172
-#define CLK_GOUT_CORE_BUS 173
-#define CLK_GOUT_CPUCL0_DBG 174
-#define CLK_GOUT_CPUCL0_SWITCH 175
-#define CLK_GOUT_CPUCL1_SWITCH 176
-#define CLK_GOUT_CPUCL2_SWITCH 177
-#define CLK_GOUT_CSIS_BUS 178
-#define CLK_GOUT_DISP_BUS 179
-#define CLK_GOUT_DNS_BUS 180
-#define CLK_GOUT_DPU_BUS 181
-#define CLK_GOUT_EH_BUS 182
-#define CLK_GOUT_G2D_G2D 183
-#define CLK_GOUT_G2D_MSCL 184
-#define CLK_GOUT_G3AA_G3AA 185
-#define CLK_GOUT_G3D_BUSD 186
-#define CLK_GOUT_G3D_GLB 187
-#define CLK_GOUT_G3D_SWITCH 188
-#define CLK_GOUT_GDC_GDC0 189
-#define CLK_GOUT_GDC_GDC1 190
-#define CLK_GOUT_GDC_SCSC 191
+#define CLK_GOUT_CMU_BUS0_BOOST 151
+#define CLK_GOUT_CMU_BUS1_BOOST 152
+#define CLK_GOUT_CMU_BUS2_BOOST 153
+#define CLK_GOUT_CMU_CORE_BOOST 154
+#define CLK_GOUT_CMU_CPUCL0_BOOST 155
+#define CLK_GOUT_CMU_CPUCL1_BOOST 156
+#define CLK_GOUT_CMU_CPUCL2_BOOST 157
+#define CLK_GOUT_CMU_MIF_BOOST 158
+#define CLK_GOUT_CMU_MIF_SWITCH 159
+#define CLK_GOUT_CMU_BO_BUS 160
+#define CLK_GOUT_CMU_BUS0_BUS 161
+#define CLK_GOUT_CMU_BUS1_BUS 162
+#define CLK_GOUT_CMU_BUS2_BUS 163
+#define CLK_GOUT_CMU_CIS_CLK0 164
+#define CLK_GOUT_CMU_CIS_CLK1 165
+#define CLK_GOUT_CMU_CIS_CLK2 166
+#define CLK_GOUT_CMU_CIS_CLK3 167
+#define CLK_GOUT_CMU_CIS_CLK4 168
+#define CLK_GOUT_CMU_CIS_CLK5 169
+#define CLK_GOUT_CMU_CIS_CLK6 170
+#define CLK_GOUT_CMU_CIS_CLK7 171
+#define CLK_GOUT_CMU_CMU_BOOST 172
+#define CLK_GOUT_CMU_CORE_BUS 173
+#define CLK_GOUT_CMU_CPUCL0_DBG 174
+#define CLK_GOUT_CMU_CPUCL0_SWITCH 175
+#define CLK_GOUT_CMU_CPUCL1_SWITCH 176
+#define CLK_GOUT_CMU_CPUCL2_SWITCH 177
+#define CLK_GOUT_CMU_CSIS_BUS 178
+#define CLK_GOUT_CMU_DISP_BUS 179
+#define CLK_GOUT_CMU_DNS_BUS 180
+#define CLK_GOUT_CMU_DPU_BUS 181
+#define CLK_GOUT_CMU_EH_BUS 182
+#define CLK_GOUT_CMU_G2D_G2D 183
+#define CLK_GOUT_CMU_G2D_MSCL 184
+#define CLK_GOUT_CMU_G3AA_G3AA 185
+#define CLK_GOUT_CMU_G3D_BUSD 186
+#define CLK_GOUT_CMU_G3D_GLB 187
+#define CLK_GOUT_CMU_G3D_SWITCH 188
+#define CLK_GOUT_CMU_GDC_GDC0 189
+#define CLK_GOUT_CMU_GDC_GDC1 190
+#define CLK_GOUT_CMU_GDC_SCSC 191
#define CLK_GOUT_CMU_HPM 192
-#define CLK_GOUT_HSI0_BUS 193
-#define CLK_GOUT_HSI0_DPGTC 194
-#define CLK_GOUT_HSI0_USB31DRD 195
-#define CLK_GOUT_HSI0_USBDPDBG 196
-#define CLK_GOUT_HSI1_BUS 197
-#define CLK_GOUT_HSI1_PCIE 198
-#define CLK_GOUT_HSI2_BUS 199
-#define CLK_GOUT_HSI2_MMC_CARD 200
-#define CLK_GOUT_HSI2_PCIE 201
-#define CLK_GOUT_HSI2_UFS_EMBD 202
-#define CLK_GOUT_IPP_BUS 203
-#define CLK_GOUT_ITP_BUS 204
-#define CLK_GOUT_MCSC_ITSC 205
-#define CLK_GOUT_MCSC_MCSC 206
-#define CLK_GOUT_MFC_MFC 207
-#define CLK_GOUT_MIF_BUSP 208
-#define CLK_GOUT_MISC_BUS 209
-#define CLK_GOUT_MISC_SSS 210
-#define CLK_GOUT_PDP_BUS 211
-#define CLK_GOUT_PDP_VRA 212
-#define CLK_GOUT_G3AA 213
-#define CLK_GOUT_PERIC0_BUS 214
-#define CLK_GOUT_PERIC0_IP 215
-#define CLK_GOUT_PERIC1_BUS 216
-#define CLK_GOUT_PERIC1_IP 217
-#define CLK_GOUT_TNR_BUS 218
-#define CLK_GOUT_TOP_CMUREF 219
-#define CLK_GOUT_TPU_BUS 220
-#define CLK_GOUT_TPU_TPU 221
-#define CLK_GOUT_TPU_TPUCTL 222
-#define CLK_GOUT_TPU_UART 223
+#define CLK_GOUT_CMU_HSI0_BUS 193
+#define CLK_GOUT_CMU_HSI0_DPGTC 194
+#define CLK_GOUT_CMU_HSI0_USB31DRD 195
+#define CLK_GOUT_CMU_HSI0_USBDPDBG 196
+#define CLK_GOUT_CMU_HSI1_BUS 197
+#define CLK_GOUT_CMU_HSI1_PCIE 198
+#define CLK_GOUT_CMU_HSI2_BUS 199
+#define CLK_GOUT_CMU_HSI2_MMC_CARD 200
+#define CLK_GOUT_CMU_HSI2_PCIE 201
+#define CLK_GOUT_CMU_HSI2_UFS_EMBD 202
+#define CLK_GOUT_CMU_IPP_BUS 203
+#define CLK_GOUT_CMU_ITP_BUS 204
+#define CLK_GOUT_CMU_MCSC_ITSC 205
+#define CLK_GOUT_CMU_MCSC_MCSC 206
+#define CLK_GOUT_CMU_MFC_MFC 207
+#define CLK_GOUT_CMU_MIF_BUSP 208
+#define CLK_GOUT_CMU_MISC_BUS 209
+#define CLK_GOUT_CMU_MISC_SSS 210
+#define CLK_GOUT_CMU_PDP_BUS 211
+#define CLK_GOUT_CMU_PDP_VRA 212
+#define CLK_GOUT_CMU_G3AA 213
+#define CLK_GOUT_CMU_PERIC0_BUS 214
+#define CLK_GOUT_CMU_PERIC0_IP 215
+#define CLK_GOUT_CMU_PERIC1_BUS 216
+#define CLK_GOUT_CMU_PERIC1_IP 217
+#define CLK_GOUT_CMU_TNR_BUS 218
+#define CLK_GOUT_CMU_TOP_CMUREF 219
+#define CLK_GOUT_CMU_TPU_BUS 220
+#define CLK_GOUT_CMU_TPU_TPU 221
+#define CLK_GOUT_CMU_TPU_TPUCTL 222
+#define CLK_GOUT_CMU_TPU_UART 223
/* CMU_APM */
#define CLK_MOUT_APM_FUNC 1
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
The gs101 clock names are derived from the clock register names under
some certain rules. In particular, for the gate clocks the following is
documented and expected in the gs101 clock driver:
Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
The CMU TOP gate clock names missed to include the required "CMU"
differentiator which will cause name collisions with the gate clock names
of other clock units. Fix the TOP gate clock names and include "CMU" in
their name.
Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/clk/samsung/clk-gs101.c | 167 ++++++++++++-----------
include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
2 files changed, 159 insertions(+), 152 deletions(-)
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index a3dda97f5eb9..0964bb11657f 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -17,7 +17,7 @@
#include "clk-exynos-arm64.h"
/* NOTE: Must be equal to the last clock ID increased by one */
-#define CLKS_NR_TOP (CLK_GOUT_TPU_UART + 1)
+#define CLKS_NR_TOP (CLK_GOUT_CMU_TPU_UART + 1)
#define CLKS_NR_APM (CLK_APM_PLL_DIV16_APM + 1)
#define CLKS_NR_MISC (CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
@@ -1259,160 +1259,167 @@ static const struct samsung_fixed_factor_clock cmu_top_ffactor[] __initconst = {
};
static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
- GATE(CLK_GOUT_BUS0_BOOST, "gout_cmu_bus0_boost",
+ GATE(CLK_GOUT_CMU_BUS0_BOOST, "gout_cmu_bus0_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS0_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_BUS1_BOOST, "gout_cmu_bus1_boost",
+ GATE(CLK_GOUT_CMU_BUS1_BOOST, "gout_cmu_bus1_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS1_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_BUS2_BOOST, "gout_cmu_bus2_boost",
+ GATE(CLK_GOUT_CMU_BUS2_BOOST, "gout_cmu_bus2_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_BUS2_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_CORE_BOOST, "gout_cmu_core_boost",
+ GATE(CLK_GOUT_CMU_CORE_BOOST, "gout_cmu_core_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CORE_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
+ GATE(CLK_GOUT_CMU_CPUCL0_BOOST, "gout_cmu_cpucl0_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL0_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
+ GATE(CLK_GOUT_CMU_CPUCL1_BOOST, "gout_cmu_cpucl1_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL1_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
+ GATE(CLK_GOUT_CMU_CPUCL2_BOOST, "gout_cmu_cpucl2_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_CPUCL2_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_MIF_BOOST, "gout_cmu_mif_boost",
+ GATE(CLK_GOUT_CMU_MIF_BOOST, "gout_cmu_mif_boost",
"mout_cmu_boost_option1", CLK_CON_GAT_CLKCMU_MIF_BOOST,
21, 0, 0),
- GATE(CLK_GOUT_MIF_SWITCH, "gout_cmu_mif_switch", "mout_cmu_mif_switch",
- CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
- GATE(CLK_GOUT_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
+ GATE(CLK_GOUT_CMU_MIF_SWITCH, "gout_cmu_mif_switch",
+ "mout_cmu_mif_switch", CLK_CON_GAT_CLKCMU_MIF_SWITCH, 21, 0, 0),
+ GATE(CLK_GOUT_CMU_BO_BUS, "gout_cmu_bo_bus", "mout_cmu_bo_bus",
CLK_CON_GAT_GATE_CLKCMU_BO_BUS, 21, 0, 0),
- GATE(CLK_GOUT_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
+ GATE(CLK_GOUT_CMU_BUS0_BUS, "gout_cmu_bus0_bus", "mout_cmu_bus0_bus",
CLK_CON_GAT_GATE_CLKCMU_BUS0_BUS, 21, 0, 0),
- GATE(CLK_GOUT_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
+ GATE(CLK_GOUT_CMU_BUS1_BUS, "gout_cmu_bus1_bus", "mout_cmu_bus1_bus",
CLK_CON_GAT_GATE_CLKCMU_BUS1_BUS, 21, 0, 0),
- GATE(CLK_GOUT_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
+ GATE(CLK_GOUT_CMU_BUS2_BUS, "gout_cmu_bus2_bus", "mout_cmu_bus2_bus",
CLK_CON_GAT_GATE_CLKCMU_BUS2_BUS, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
+ GATE(CLK_GOUT_CMU_CIS_CLK0, "gout_cmu_cis_clk0", "mout_cmu_cis_clk0",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK0, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
+ GATE(CLK_GOUT_CMU_CIS_CLK1, "gout_cmu_cis_clk1", "mout_cmu_cis_clk1",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK1, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
+ GATE(CLK_GOUT_CMU_CIS_CLK2, "gout_cmu_cis_clk2", "mout_cmu_cis_clk2",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK2, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
+ GATE(CLK_GOUT_CMU_CIS_CLK3, "gout_cmu_cis_clk3", "mout_cmu_cis_clk3",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK3, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
+ GATE(CLK_GOUT_CMU_CIS_CLK4, "gout_cmu_cis_clk4", "mout_cmu_cis_clk4",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK4, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
+ GATE(CLK_GOUT_CMU_CIS_CLK5, "gout_cmu_cis_clk5", "mout_cmu_cis_clk5",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK5, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
+ GATE(CLK_GOUT_CMU_CIS_CLK6, "gout_cmu_cis_clk6", "mout_cmu_cis_clk6",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK6, 21, 0, 0),
- GATE(CLK_GOUT_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
+ GATE(CLK_GOUT_CMU_CIS_CLK7, "gout_cmu_cis_clk7", "mout_cmu_cis_clk7",
CLK_CON_GAT_GATE_CLKCMU_CIS_CLK7, 21, 0, 0),
- GATE(CLK_GOUT_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
+ GATE(CLK_GOUT_CMU_CMU_BOOST, "gout_cmu_cmu_boost", "mout_cmu_cmu_boost",
CLK_CON_GAT_GATE_CLKCMU_CMU_BOOST, 21, 0, 0),
- GATE(CLK_GOUT_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
+ GATE(CLK_GOUT_CMU_CORE_BUS, "gout_cmu_core_bus", "mout_cmu_core_bus",
CLK_CON_GAT_GATE_CLKCMU_CORE_BUS, 21, 0, 0),
- GATE(CLK_GOUT_CPUCL0_DBG, "gout_cmu_cpucl0_dbg", "mout_cmu_cpucl0_dbg",
- CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS, 21, 0, 0),
- GATE(CLK_GOUT_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
+ GATE(CLK_GOUT_CMU_CPUCL0_DBG, "gout_cmu_cpucl0_dbg",
+ "mout_cmu_cpucl0_dbg", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_DBG_BUS,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_CPUCL0_SWITCH, "gout_cmu_cpucl0_switch",
"mout_cmu_cpucl0_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL0_SWITCH,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
+ GATE(CLK_GOUT_CMU_CPUCL1_SWITCH, "gout_cmu_cpucl1_switch",
"mout_cmu_cpucl1_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL1_SWITCH,
21, 0, 0),
- GATE(CLK_GOUT_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
+ GATE(CLK_GOUT_CMU_CPUCL2_SWITCH, "gout_cmu_cpucl2_switch",
"mout_cmu_cpucl2_switch", CLK_CON_GAT_GATE_CLKCMU_CPUCL2_SWITCH,
21, 0, 0),
- GATE(CLK_GOUT_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
+ GATE(CLK_GOUT_CMU_CSIS_BUS, "gout_cmu_csis_bus", "mout_cmu_csis_bus",
CLK_CON_GAT_GATE_CLKCMU_CSIS_BUS, 21, 0, 0),
- GATE(CLK_GOUT_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
+ GATE(CLK_GOUT_CMU_DISP_BUS, "gout_cmu_disp_bus", "mout_cmu_disp_bus",
CLK_CON_GAT_GATE_CLKCMU_DISP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
+ GATE(CLK_GOUT_CMU_DNS_BUS, "gout_cmu_dns_bus", "mout_cmu_dns_bus",
CLK_CON_GAT_GATE_CLKCMU_DNS_BUS, 21, 0, 0),
- GATE(CLK_GOUT_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
+ GATE(CLK_GOUT_CMU_DPU_BUS, "gout_cmu_dpu_bus", "mout_cmu_dpu_bus",
CLK_CON_GAT_GATE_CLKCMU_DPU_BUS, 21, 0, 0),
- GATE(CLK_GOUT_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
+ GATE(CLK_GOUT_CMU_EH_BUS, "gout_cmu_eh_bus", "mout_cmu_eh_bus",
CLK_CON_GAT_GATE_CLKCMU_EH_BUS, 21, 0, 0),
- GATE(CLK_GOUT_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
+ GATE(CLK_GOUT_CMU_G2D_G2D, "gout_cmu_g2d_g2d", "mout_cmu_g2d_g2d",
CLK_CON_GAT_GATE_CLKCMU_G2D_G2D, 21, 0, 0),
- GATE(CLK_GOUT_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
+ GATE(CLK_GOUT_CMU_G2D_MSCL, "gout_cmu_g2d_mscl", "mout_cmu_g2d_mscl",
CLK_CON_GAT_GATE_CLKCMU_G2D_MSCL, 21, 0, 0),
- GATE(CLK_GOUT_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
+ GATE(CLK_GOUT_CMU_G3AA_G3AA, "gout_cmu_g3aa_g3aa", "mout_cmu_g3aa_g3aa",
CLK_CON_MUX_MUX_CLKCMU_G3AA_G3AA, 21, 0, 0),
- GATE(CLK_GOUT_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
+ GATE(CLK_GOUT_CMU_G3D_BUSD, "gout_cmu_g3d_busd", "mout_cmu_g3d_busd",
CLK_CON_GAT_GATE_CLKCMU_G3D_BUSD, 21, 0, 0),
- GATE(CLK_GOUT_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
+ GATE(CLK_GOUT_CMU_G3D_GLB, "gout_cmu_g3d_glb", "mout_cmu_g3d_glb",
CLK_CON_GAT_GATE_CLKCMU_G3D_GLB, 21, 0, 0),
- GATE(CLK_GOUT_G3D_SWITCH, "gout_cmu_g3d_switch", "mout_cmu_g3d_switch",
- CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH, 21, 0, 0),
- GATE(CLK_GOUT_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
+ GATE(CLK_GOUT_CMU_G3D_SWITCH, "gout_cmu_g3d_switch",
+ "mout_cmu_g3d_switch", CLK_CON_GAT_GATE_CLKCMU_G3D_SWITCH,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_GDC_GDC0, "gout_cmu_gdc_gdc0", "mout_cmu_gdc_gdc0",
CLK_CON_GAT_GATE_CLKCMU_GDC_GDC0, 21, 0, 0),
- GATE(CLK_GOUT_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
+ GATE(CLK_GOUT_CMU_GDC_GDC1, "gout_cmu_gdc_gdc1", "mout_cmu_gdc_gdc1",
CLK_CON_GAT_GATE_CLKCMU_GDC_GDC1, 21, 0, 0),
- GATE(CLK_GOUT_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
+ GATE(CLK_GOUT_CMU_GDC_SCSC, "gout_cmu_gdc_scsc", "mout_cmu_gdc_scsc",
CLK_CON_GAT_GATE_CLKCMU_GDC_SCSC, 21, 0, 0),
GATE(CLK_GOUT_CMU_HPM, "gout_cmu_hpm", "mout_cmu_hpm",
CLK_CON_GAT_GATE_CLKCMU_HPM, 21, 0, 0),
- GATE(CLK_GOUT_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
+ GATE(CLK_GOUT_CMU_HSI0_BUS, "gout_cmu_hsi0_bus", "mout_cmu_hsi0_bus",
CLK_CON_GAT_GATE_CLKCMU_HSI0_BUS, 21, 0, 0),
- GATE(CLK_GOUT_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc", "mout_cmu_hsi0_dpgtc",
- CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC, 21, 0, 0),
- GATE(CLK_GOUT_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
+ GATE(CLK_GOUT_CMU_HSI0_DPGTC, "gout_cmu_hsi0_dpgtc",
+ "mout_cmu_hsi0_dpgtc", CLK_CON_GAT_GATE_CLKCMU_HSI0_DPGTC,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_HSI0_USB31DRD, "gout_cmu_hsi0_usb31drd",
"mout_cmu_hsi0_usb31drd", CLK_CON_GAT_GATE_CLKCMU_HSI0_USB31DRD,
21, 0, 0),
- GATE(CLK_GOUT_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
+ GATE(CLK_GOUT_CMU_HSI0_USBDPDBG, "gout_cmu_hsi0_usbdpdbg",
"mout_cmu_hsi0_usbdpdbg", CLK_CON_GAT_GATE_CLKCMU_HSI0_USBDPDBG,
21, 0, 0),
- GATE(CLK_GOUT_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
+ GATE(CLK_GOUT_CMU_HSI1_BUS, "gout_cmu_hsi1_bus", "mout_cmu_hsi1_bus",
CLK_CON_GAT_GATE_CLKCMU_HSI1_BUS, 21, 0, 0),
- GATE(CLK_GOUT_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
+ GATE(CLK_GOUT_CMU_HSI1_PCIE, "gout_cmu_hsi1_pcie", "mout_cmu_hsi1_pcie",
CLK_CON_GAT_GATE_CLKCMU_HSI1_PCIE, 21, 0, 0),
- GATE(CLK_GOUT_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
+ GATE(CLK_GOUT_CMU_HSI2_BUS, "gout_cmu_hsi2_bus", "mout_cmu_hsi2_bus",
CLK_CON_GAT_GATE_CLKCMU_HSI2_BUS, 21, 0, 0),
- GATE(CLK_GOUT_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
+ GATE(CLK_GOUT_CMU_HSI2_MMC_CARD, "gout_cmu_hsi2_mmc_card",
"mout_cmu_hsi2_mmc_card", CLK_CON_GAT_GATE_CLKCMU_HSI2_MMCCARD,
21, 0, 0),
- GATE(CLK_GOUT_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
+ GATE(CLK_GOUT_CMU_HSI2_PCIE, "gout_cmu_hsi2_pcie", "mout_cmu_hsi2_pcie",
CLK_CON_GAT_GATE_CLKCMU_HSI2_PCIE, 21, 0, 0),
- GATE(CLK_GOUT_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
+ GATE(CLK_GOUT_CMU_HSI2_UFS_EMBD, "gout_cmu_hsi2_ufs_embd",
"mout_cmu_hsi2_ufs_embd", CLK_CON_GAT_GATE_CLKCMU_HSI2_UFS_EMBD,
21, 0, 0),
- GATE(CLK_GOUT_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
+ GATE(CLK_GOUT_CMU_IPP_BUS, "gout_cmu_ipp_bus", "mout_cmu_ipp_bus",
CLK_CON_GAT_GATE_CLKCMU_IPP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
+ GATE(CLK_GOUT_CMU_ITP_BUS, "gout_cmu_itp_bus", "mout_cmu_itp_bus",
CLK_CON_GAT_GATE_CLKCMU_ITP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
+ GATE(CLK_GOUT_CMU_MCSC_ITSC, "gout_cmu_mcsc_itsc", "mout_cmu_mcsc_itsc",
CLK_CON_GAT_GATE_CLKCMU_MCSC_ITSC, 21, 0, 0),
- GATE(CLK_GOUT_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
+ GATE(CLK_GOUT_CMU_MCSC_MCSC, "gout_cmu_mcsc_mcsc", "mout_cmu_mcsc_mcsc",
CLK_CON_GAT_GATE_CLKCMU_MCSC_MCSC, 21, 0, 0),
- GATE(CLK_GOUT_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
+ GATE(CLK_GOUT_CMU_MFC_MFC, "gout_cmu_mfc_mfc", "mout_cmu_mfc_mfc",
CLK_CON_GAT_GATE_CLKCMU_MFC_MFC, 21, 0, 0),
- GATE(CLK_GOUT_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
+ GATE(CLK_GOUT_CMU_MIF_BUSP, "gout_cmu_mif_busp", "mout_cmu_mif_busp",
CLK_CON_GAT_GATE_CLKCMU_MIF_BUSP, 21, 0, 0),
- GATE(CLK_GOUT_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
+ GATE(CLK_GOUT_CMU_MISC_BUS, "gout_cmu_misc_bus", "mout_cmu_misc_bus",
CLK_CON_GAT_GATE_CLKCMU_MISC_BUS, 21, 0, 0),
- GATE(CLK_GOUT_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
+ GATE(CLK_GOUT_CMU_MISC_SSS, "gout_cmu_misc_sss", "mout_cmu_misc_sss",
CLK_CON_GAT_GATE_CLKCMU_MISC_SSS, 21, 0, 0),
- GATE(CLK_GOUT_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
+ GATE(CLK_GOUT_CMU_PDP_BUS, "gout_cmu_pdp_bus", "mout_cmu_pdp_bus",
CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
+ GATE(CLK_GOUT_CMU_PDP_VRA, "gout_cmu_pdp_vra", "mout_cmu_pdp_vra",
CLK_CON_GAT_GATE_CLKCMU_PDP_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PERIC0_BUS, "gout_cmu_peric0_bus", "mout_cmu_peric0_bus",
- CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
+ GATE(CLK_GOUT_CMU_PERIC0_BUS, "gout_cmu_peric0_bus",
+ "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
- GATE(CLK_GOUT_PERIC1_BUS, "gout_cmu_peric1_bus", "mout_cmu_peric1_bus",
- CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS, 21, 0, 0),
- GATE(CLK_GOUT_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
+ GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
+ "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_PERIC1_IP, "gout_cmu_peric1_ip", "mout_cmu_peric1_ip",
CLK_CON_GAT_GATE_CLKCMU_PERIC1_IP, 21, 0, 0),
- GATE(CLK_GOUT_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
+ GATE(CLK_GOUT_CMU_TNR_BUS, "gout_cmu_tnr_bus", "mout_cmu_tnr_bus",
CLK_CON_GAT_GATE_CLKCMU_TNR_BUS, 21, 0, 0),
- GATE(CLK_GOUT_TOP_CMUREF, "gout_cmu_top_cmuref", "mout_cmu_top_cmuref",
- CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF, 21, 0, 0),
- GATE(CLK_GOUT_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
+ GATE(CLK_GOUT_CMU_TOP_CMUREF, "gout_cmu_top_cmuref",
+ "mout_cmu_top_cmuref", CLK_CON_GAT_GATE_CLKCMU_TOP_CMUREF,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_TPU_BUS, "gout_cmu_tpu_bus", "mout_cmu_tpu_bus",
CLK_CON_GAT_GATE_CLKCMU_TPU_BUS, 21, 0, 0),
- GATE(CLK_GOUT_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
+ GATE(CLK_GOUT_CMU_TPU_TPU, "gout_cmu_tpu_tpu", "mout_cmu_tpu_tpu",
CLK_CON_GAT_GATE_CLKCMU_TPU_TPU, 21, 0, 0),
- GATE(CLK_GOUT_TPU_TPUCTL, "gout_cmu_tpu_tpuctl", "mout_cmu_tpu_tpuctl",
- CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL, 21, 0, 0),
- GATE(CLK_GOUT_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
+ GATE(CLK_GOUT_CMU_TPU_TPUCTL, "gout_cmu_tpu_tpuctl",
+ "mout_cmu_tpu_tpuctl", CLK_CON_GAT_GATE_CLKCMU_TPU_TPUCTL,
+ 21, 0, 0),
+ GATE(CLK_GOUT_CMU_TPU_UART, "gout_cmu_tpu_uart", "mout_cmu_tpu_uart",
CLK_CON_GAT_GATE_CLKCMU_TPU_UART, 21, 0, 0),
};
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 9761c0b24e66..21adec22387c 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -166,79 +166,79 @@
#define CLK_DOUT_CMU_SHARED3_DIV2 150
/* CMU_TOP Gates */
-#define CLK_GOUT_BUS0_BOOST 151
-#define CLK_GOUT_BUS1_BOOST 152
-#define CLK_GOUT_BUS2_BOOST 153
-#define CLK_GOUT_CORE_BOOST 154
-#define CLK_GOUT_CPUCL0_BOOST 155
-#define CLK_GOUT_CPUCL1_BOOST 156
-#define CLK_GOUT_CPUCL2_BOOST 157
-#define CLK_GOUT_MIF_BOOST 158
-#define CLK_GOUT_MIF_SWITCH 159
-#define CLK_GOUT_BO_BUS 160
-#define CLK_GOUT_BUS0_BUS 161
-#define CLK_GOUT_BUS1_BUS 162
-#define CLK_GOUT_BUS2_BUS 163
-#define CLK_GOUT_CIS_CLK0 164
-#define CLK_GOUT_CIS_CLK1 165
-#define CLK_GOUT_CIS_CLK2 166
-#define CLK_GOUT_CIS_CLK3 167
-#define CLK_GOUT_CIS_CLK4 168
-#define CLK_GOUT_CIS_CLK5 169
-#define CLK_GOUT_CIS_CLK6 170
-#define CLK_GOUT_CIS_CLK7 171
-#define CLK_GOUT_CMU_BOOST 172
-#define CLK_GOUT_CORE_BUS 173
-#define CLK_GOUT_CPUCL0_DBG 174
-#define CLK_GOUT_CPUCL0_SWITCH 175
-#define CLK_GOUT_CPUCL1_SWITCH 176
-#define CLK_GOUT_CPUCL2_SWITCH 177
-#define CLK_GOUT_CSIS_BUS 178
-#define CLK_GOUT_DISP_BUS 179
-#define CLK_GOUT_DNS_BUS 180
-#define CLK_GOUT_DPU_BUS 181
-#define CLK_GOUT_EH_BUS 182
-#define CLK_GOUT_G2D_G2D 183
-#define CLK_GOUT_G2D_MSCL 184
-#define CLK_GOUT_G3AA_G3AA 185
-#define CLK_GOUT_G3D_BUSD 186
-#define CLK_GOUT_G3D_GLB 187
-#define CLK_GOUT_G3D_SWITCH 188
-#define CLK_GOUT_GDC_GDC0 189
-#define CLK_GOUT_GDC_GDC1 190
-#define CLK_GOUT_GDC_SCSC 191
+#define CLK_GOUT_CMU_BUS0_BOOST 151
+#define CLK_GOUT_CMU_BUS1_BOOST 152
+#define CLK_GOUT_CMU_BUS2_BOOST 153
+#define CLK_GOUT_CMU_CORE_BOOST 154
+#define CLK_GOUT_CMU_CPUCL0_BOOST 155
+#define CLK_GOUT_CMU_CPUCL1_BOOST 156
+#define CLK_GOUT_CMU_CPUCL2_BOOST 157
+#define CLK_GOUT_CMU_MIF_BOOST 158
+#define CLK_GOUT_CMU_MIF_SWITCH 159
+#define CLK_GOUT_CMU_BO_BUS 160
+#define CLK_GOUT_CMU_BUS0_BUS 161
+#define CLK_GOUT_CMU_BUS1_BUS 162
+#define CLK_GOUT_CMU_BUS2_BUS 163
+#define CLK_GOUT_CMU_CIS_CLK0 164
+#define CLK_GOUT_CMU_CIS_CLK1 165
+#define CLK_GOUT_CMU_CIS_CLK2 166
+#define CLK_GOUT_CMU_CIS_CLK3 167
+#define CLK_GOUT_CMU_CIS_CLK4 168
+#define CLK_GOUT_CMU_CIS_CLK5 169
+#define CLK_GOUT_CMU_CIS_CLK6 170
+#define CLK_GOUT_CMU_CIS_CLK7 171
+#define CLK_GOUT_CMU_CMU_BOOST 172
+#define CLK_GOUT_CMU_CORE_BUS 173
+#define CLK_GOUT_CMU_CPUCL0_DBG 174
+#define CLK_GOUT_CMU_CPUCL0_SWITCH 175
+#define CLK_GOUT_CMU_CPUCL1_SWITCH 176
+#define CLK_GOUT_CMU_CPUCL2_SWITCH 177
+#define CLK_GOUT_CMU_CSIS_BUS 178
+#define CLK_GOUT_CMU_DISP_BUS 179
+#define CLK_GOUT_CMU_DNS_BUS 180
+#define CLK_GOUT_CMU_DPU_BUS 181
+#define CLK_GOUT_CMU_EH_BUS 182
+#define CLK_GOUT_CMU_G2D_G2D 183
+#define CLK_GOUT_CMU_G2D_MSCL 184
+#define CLK_GOUT_CMU_G3AA_G3AA 185
+#define CLK_GOUT_CMU_G3D_BUSD 186
+#define CLK_GOUT_CMU_G3D_GLB 187
+#define CLK_GOUT_CMU_G3D_SWITCH 188
+#define CLK_GOUT_CMU_GDC_GDC0 189
+#define CLK_GOUT_CMU_GDC_GDC1 190
+#define CLK_GOUT_CMU_GDC_SCSC 191
#define CLK_GOUT_CMU_HPM 192
-#define CLK_GOUT_HSI0_BUS 193
-#define CLK_GOUT_HSI0_DPGTC 194
-#define CLK_GOUT_HSI0_USB31DRD 195
-#define CLK_GOUT_HSI0_USBDPDBG 196
-#define CLK_GOUT_HSI1_BUS 197
-#define CLK_GOUT_HSI1_PCIE 198
-#define CLK_GOUT_HSI2_BUS 199
-#define CLK_GOUT_HSI2_MMC_CARD 200
-#define CLK_GOUT_HSI2_PCIE 201
-#define CLK_GOUT_HSI2_UFS_EMBD 202
-#define CLK_GOUT_IPP_BUS 203
-#define CLK_GOUT_ITP_BUS 204
-#define CLK_GOUT_MCSC_ITSC 205
-#define CLK_GOUT_MCSC_MCSC 206
-#define CLK_GOUT_MFC_MFC 207
-#define CLK_GOUT_MIF_BUSP 208
-#define CLK_GOUT_MISC_BUS 209
-#define CLK_GOUT_MISC_SSS 210
-#define CLK_GOUT_PDP_BUS 211
-#define CLK_GOUT_PDP_VRA 212
-#define CLK_GOUT_G3AA 213
-#define CLK_GOUT_PERIC0_BUS 214
-#define CLK_GOUT_PERIC0_IP 215
-#define CLK_GOUT_PERIC1_BUS 216
-#define CLK_GOUT_PERIC1_IP 217
-#define CLK_GOUT_TNR_BUS 218
-#define CLK_GOUT_TOP_CMUREF 219
-#define CLK_GOUT_TPU_BUS 220
-#define CLK_GOUT_TPU_TPU 221
-#define CLK_GOUT_TPU_TPUCTL 222
-#define CLK_GOUT_TPU_UART 223
+#define CLK_GOUT_CMU_HSI0_BUS 193
+#define CLK_GOUT_CMU_HSI0_DPGTC 194
+#define CLK_GOUT_CMU_HSI0_USB31DRD 195
+#define CLK_GOUT_CMU_HSI0_USBDPDBG 196
+#define CLK_GOUT_CMU_HSI1_BUS 197
+#define CLK_GOUT_CMU_HSI1_PCIE 198
+#define CLK_GOUT_CMU_HSI2_BUS 199
+#define CLK_GOUT_CMU_HSI2_MMC_CARD 200
+#define CLK_GOUT_CMU_HSI2_PCIE 201
+#define CLK_GOUT_CMU_HSI2_UFS_EMBD 202
+#define CLK_GOUT_CMU_IPP_BUS 203
+#define CLK_GOUT_CMU_ITP_BUS 204
+#define CLK_GOUT_CMU_MCSC_ITSC 205
+#define CLK_GOUT_CMU_MCSC_MCSC 206
+#define CLK_GOUT_CMU_MFC_MFC 207
+#define CLK_GOUT_CMU_MIF_BUSP 208
+#define CLK_GOUT_CMU_MISC_BUS 209
+#define CLK_GOUT_CMU_MISC_SSS 210
+#define CLK_GOUT_CMU_PDP_BUS 211
+#define CLK_GOUT_CMU_PDP_VRA 212
+#define CLK_GOUT_CMU_G3AA 213
+#define CLK_GOUT_CMU_PERIC0_BUS 214
+#define CLK_GOUT_CMU_PERIC0_IP 215
+#define CLK_GOUT_CMU_PERIC1_BUS 216
+#define CLK_GOUT_CMU_PERIC1_IP 217
+#define CLK_GOUT_CMU_TNR_BUS 218
+#define CLK_GOUT_CMU_TOP_CMUREF 219
+#define CLK_GOUT_CMU_TPU_BUS 220
+#define CLK_GOUT_CMU_TPU_TPU 221
+#define CLK_GOUT_CMU_TPU_TPUCTL 222
+#define CLK_GOUT_CMU_TPU_UART 223
/* CMU_APM */
#define CLK_MOUT_APM_FUNC 1
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
clock management unit.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
.../bindings/clock/google,gs101-clock.yaml | 25 +++++-
include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
2 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
index 3eebc03a309b..ba54c13c55bc 100644
--- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -30,14 +30,15 @@ properties:
- google,gs101-cmu-top
- google,gs101-cmu-apm
- google,gs101-cmu-misc
+ - google,gs101-cmu-peric0
clocks:
minItems: 1
- maxItems: 2
+ maxItems: 3
clock-names:
minItems: 1
- maxItems: 2
+ maxItems: 3
"#clock-cells":
const: 1
@@ -88,6 +89,26 @@ allOf:
- const: dout_cmu_misc_bus
- const: dout_cmu_misc_sss
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-cmu-peric0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (24.576 MHz)
+ - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
+ - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: dout_cmu_peric0_bus
+ - const: dout_cmu_peric0_ip
+
additionalProperties: false
examples:
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 21adec22387c..7d7a896416a7 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -389,4 +389,90 @@
#define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK 73
#define CLK_GOUT_MISC_XIU_D_MISC_ACLK 74
+/* CMU_PERIC0 */
+/* CMU_PERIC0 MUX */
+#define CLK_MOUT_PERIC0_BUS_USER 1
+#define CLK_MOUT_PERIC0_I3C_USER 2
+#define CLK_MOUT_PERIC0_USI0_UART_USER 3
+#define CLK_MOUT_PERIC0_USI14_USI_USER 4
+#define CLK_MOUT_PERIC0_USI1_USI_USER 5
+#define CLK_MOUT_PERIC0_USI2_USI_USER 6
+#define CLK_MOUT_PERIC0_USI3_USI_USER 7
+#define CLK_MOUT_PERIC0_USI4_USI_USER 8
+#define CLK_MOUT_PERIC0_USI5_USI_USER 9
+#define CLK_MOUT_PERIC0_USI6_USI_USER 10
+#define CLK_MOUT_PERIC0_USI7_USI_USER 11
+#define CLK_MOUT_PERIC0_USI8_USI_USER 12
+
+/* CMU_PERIC0 Dividers */
+#define CLK_DOUT_PERIC0_I3C 13
+#define CLK_DOUT_PERIC0_USI0_UART 14
+#define CLK_DOUT_PERIC0_USI14_USI 15
+#define CLK_DOUT_PERIC0_USI1_USI 16
+#define CLK_DOUT_PERIC0_USI2_USI 17
+#define CLK_DOUT_PERIC0_USI3_USI 18
+#define CLK_DOUT_PERIC0_USI4_USI 19
+#define CLK_DOUT_PERIC0_USI5_USI 20
+#define CLK_DOUT_PERIC0_USI6_USI 21
+#define CLK_DOUT_PERIC0_USI7_USI 22
+#define CLK_DOUT_PERIC0_USI8_USI 23
+
+/* CMU_PERIC0 Gates */
+#define CLK_GOUT_PERIC0_IP 24
+#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK 25
+#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK 26
+#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK 27
+#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK 28
+#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK 29
+#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK 30
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0 31
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1 32
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10 33
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11 34
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12 35
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13 36
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14 37
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15 38
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2 39
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3 40
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4 41
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5 42
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6 43
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7 44
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8 45
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9 46
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0 47
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1 48
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10 49
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11 50
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12 51
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13 52
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14 53
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15 54
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2 55
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3 56
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4 57
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5 58
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6 59
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7 60
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8 61
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9 62
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0 63
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2 64
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0 65
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2 66
+#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK 67
+#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK 68
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK 69
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK 70
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK 71
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK 72
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK 73
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK 74
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK 75
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK 76
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK 77
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK 78
+#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK 79
+
#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
clock management unit.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
.../bindings/clock/google,gs101-clock.yaml | 25 +++++-
include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
2 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
index 3eebc03a309b..ba54c13c55bc 100644
--- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
@@ -30,14 +30,15 @@ properties:
- google,gs101-cmu-top
- google,gs101-cmu-apm
- google,gs101-cmu-misc
+ - google,gs101-cmu-peric0
clocks:
minItems: 1
- maxItems: 2
+ maxItems: 3
clock-names:
minItems: 1
- maxItems: 2
+ maxItems: 3
"#clock-cells":
const: 1
@@ -88,6 +89,26 @@ allOf:
- const: dout_cmu_misc_bus
- const: dout_cmu_misc_sss
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: google,gs101-cmu-peric0
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: External reference clock (24.576 MHz)
+ - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
+ - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
+
+ clock-names:
+ items:
+ - const: oscclk
+ - const: dout_cmu_peric0_bus
+ - const: dout_cmu_peric0_ip
+
additionalProperties: false
examples:
diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
index 21adec22387c..7d7a896416a7 100644
--- a/include/dt-bindings/clock/google,gs101.h
+++ b/include/dt-bindings/clock/google,gs101.h
@@ -389,4 +389,90 @@
#define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK 73
#define CLK_GOUT_MISC_XIU_D_MISC_ACLK 74
+/* CMU_PERIC0 */
+/* CMU_PERIC0 MUX */
+#define CLK_MOUT_PERIC0_BUS_USER 1
+#define CLK_MOUT_PERIC0_I3C_USER 2
+#define CLK_MOUT_PERIC0_USI0_UART_USER 3
+#define CLK_MOUT_PERIC0_USI14_USI_USER 4
+#define CLK_MOUT_PERIC0_USI1_USI_USER 5
+#define CLK_MOUT_PERIC0_USI2_USI_USER 6
+#define CLK_MOUT_PERIC0_USI3_USI_USER 7
+#define CLK_MOUT_PERIC0_USI4_USI_USER 8
+#define CLK_MOUT_PERIC0_USI5_USI_USER 9
+#define CLK_MOUT_PERIC0_USI6_USI_USER 10
+#define CLK_MOUT_PERIC0_USI7_USI_USER 11
+#define CLK_MOUT_PERIC0_USI8_USI_USER 12
+
+/* CMU_PERIC0 Dividers */
+#define CLK_DOUT_PERIC0_I3C 13
+#define CLK_DOUT_PERIC0_USI0_UART 14
+#define CLK_DOUT_PERIC0_USI14_USI 15
+#define CLK_DOUT_PERIC0_USI1_USI 16
+#define CLK_DOUT_PERIC0_USI2_USI 17
+#define CLK_DOUT_PERIC0_USI3_USI 18
+#define CLK_DOUT_PERIC0_USI4_USI 19
+#define CLK_DOUT_PERIC0_USI5_USI 20
+#define CLK_DOUT_PERIC0_USI6_USI 21
+#define CLK_DOUT_PERIC0_USI7_USI 22
+#define CLK_DOUT_PERIC0_USI8_USI 23
+
+/* CMU_PERIC0 Gates */
+#define CLK_GOUT_PERIC0_IP 24
+#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK 25
+#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK 26
+#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK 27
+#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK 28
+#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK 29
+#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK 30
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0 31
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1 32
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10 33
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11 34
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12 35
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13 36
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14 37
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15 38
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2 39
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3 40
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4 41
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5 42
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6 43
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7 44
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8 45
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9 46
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0 47
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1 48
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10 49
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11 50
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12 51
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13 52
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14 53
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15 54
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2 55
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3 56
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4 57
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5 58
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6 59
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7 60
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8 61
+#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9 62
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0 63
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2 64
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0 65
+#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2 66
+#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK 67
+#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK 68
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK 69
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK 70
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK 71
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK 72
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK 73
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK 74
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK 75
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK 76
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK 77
+#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK 78
+#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK 79
+
#endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Add google,gs101-hsi2c dedicated compatible for representing
I2C of Google GS101 SoC.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index df9c57bca2a8..cc8bba5537b9 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -33,6 +33,7 @@ properties:
- const: samsung,exynos7-hsi2c
- items:
- enum:
+ - google,gs101-hsi2c
- samsung,exynos850-hsi2c
- const: samsung,exynosautov9-hsi2c
- const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Add google,gs101-hsi2c dedicated compatible for representing
I2C of Google GS101 SoC.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index df9c57bca2a8..cc8bba5537b9 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -33,6 +33,7 @@ properties:
- const: samsung,exynos7-hsi2c
- items:
- enum:
+ - google,gs101-hsi2c
- samsung,exynos850-hsi2c
- const: samsung,exynosautov9-hsi2c
- const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
GS101 only allows 32-bit register accesses. When using 8-bit reg
accesses on gs101, a SError Interrupt is raised causing the system
unusable.
Make reg-io-width a required property and expect for it a value of 4.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 133259ed3a34..cc896d7e2a3d 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -143,6 +143,10 @@ allOf:
then:
required:
- samsung,uart-fifosize
+ - reg-io-width
+ properties:
+ reg-io-width:
+ const: 4
unevaluatedProperties: false
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
GS101 only allows 32-bit register accesses. When using 8-bit reg
accesses on gs101, a SError Interrupt is raised causing the system
unusable.
Make reg-io-width a required property and expect for it a value of 4.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index 133259ed3a34..cc896d7e2a3d 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -143,6 +143,10 @@ allOf:
then:
required:
- samsung,uart-fifosize
+ - reg-io-width
+ properties:
+ reg-io-width:
+ const: 4
unevaluatedProperties: false
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
GS101 only allows 32-bit register accesses. If using 8-bit register
accesses on gs101, a SError Interrupt is raised causing the system
unusable.
Force the reg accesses to MMIO32 regardless of the user's settings.
This is a common practice for such earlycons (bcm2835aux, uniphier,
lpuart32), in order to avoid crashing the kernel with a wrong early
console definition.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/tty/serial/samsung_tty.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 66bd6c090ace..19cd3e6a9b6e 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2787,6 +2787,17 @@ OF_EARLYCON_DECLARE(exynos4210, "samsung,exynos4210-uart",
OF_EARLYCON_DECLARE(artpec8, "axis,artpec8-uart",
s5pv210_early_console_setup);
+static int __init gs101_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ /* gs101 always expects MMIO32 register accesses. */
+ device->port.iotype = UPIO_MEM32;
+
+ return s5pv210_early_console_setup(device, opt);
+}
+
+OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
+
/* Apple S5L */
static int __init apple_s5l_early_console_setup(struct earlycon_device *device,
const char *opt)
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
GS101 only allows 32-bit register accesses. If using 8-bit register
accesses on gs101, a SError Interrupt is raised causing the system
unusable.
Force the reg accesses to MMIO32 regardless of the user's settings.
This is a common practice for such earlycons (bcm2835aux, uniphier,
lpuart32), in order to avoid crashing the kernel with a wrong early
console definition.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/tty/serial/samsung_tty.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index 66bd6c090ace..19cd3e6a9b6e 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2787,6 +2787,17 @@ OF_EARLYCON_DECLARE(exynos4210, "samsung,exynos4210-uart",
OF_EARLYCON_DECLARE(artpec8, "axis,artpec8-uart",
s5pv210_early_console_setup);
+static int __init gs101_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ /* gs101 always expects MMIO32 register accesses. */
+ device->port.iotype = UPIO_MEM32;
+
+ return s5pv210_early_console_setup(device, opt);
+}
+
+OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
+
/* Apple S5L */
static int __init apple_s5l_early_console_setup(struct earlycon_device *device,
const char *opt)
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 06/13] clk: samsung: gs101: add support for cmu_peric0
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
CMU_PERIC0 is the clock management unit used for the peric0 block which
is used for USI and I3C. Add support for cmu_peric0.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/clk/samsung/clk-gs101.c | 579 ++++++++++++++++++++++++++++++++
1 file changed, 579 insertions(+)
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 0964bb11657f..3d194520b05e 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -20,6 +20,7 @@
#define CLKS_NR_TOP (CLK_GOUT_CMU_TPU_UART + 1)
#define CLKS_NR_APM (CLK_APM_PLL_DIV16_APM + 1)
#define CLKS_NR_MISC (CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
+#define CLKS_NR_PERIC0 (CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK + 1)
/* ---- CMU_TOP ------------------------------------------------------------- */
@@ -2478,6 +2479,581 @@ static const struct samsung_cmu_info misc_cmu_info __initconst = {
.clk_name = "dout_cmu_misc_bus",
};
+/* ---- CMU_PERIC0 --------------------------------------------------------- */
+
+/* Register Offset definitions for CMU_PERIC0 (0x10800000) */
+#define PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER 0x0600
+#define PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER 0x0604
+#define PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER 0x0610
+#define PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER 0x0614
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER 0x0620
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER 0x0624
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER 0x0640
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER 0x0644
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER 0x0650
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER 0x0654
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER 0x0660
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER 0x0664
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER 0x0670
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER 0x0674
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER 0x0680
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER 0x0684
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER 0x0690
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER 0x0694
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER 0x06a0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER 0x06a4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER 0x06b0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER 0x06b4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER 0x06c0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER 0x06c4
+#define PERIC0_CMU_PERIC0_CONTROLLER_OPTION 0x0800
+#define CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0 0x0810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_I3C 0x1800
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART 0x1804
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI 0x180c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI 0x1810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI 0x1814
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI 0x1820
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI 0x1824
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI 0x1828
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI 0x182c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI 0x1830
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI 0x1834
+#define CLK_CON_BUF_CLKBUF_PERIC0_IP 0x2000
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK 0x2004
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK 0x2008
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK 0x200c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK 0x2010
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK 0x2014
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK 0x2018
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0 0x201c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1 0x2020
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10 0x2024
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11 0x2028
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12 0x202c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13 0x2030
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14 0x2034
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15 0x2038
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2 0x203c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3 0x2040
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4 0x2044
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5 0x2048
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6 0x204c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7 0x2050
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8 0x2054
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9 0x2058
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0 0x205c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1 0x2060
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10 0x2064
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11 0x2068
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12 0x206c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13 0x2070
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14 0x2074
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15 0x2078
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2 0x207c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3 0x2080
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4 0x2084
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5 0x2088
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6 0x208c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7 0x2090
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8 0x2094
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9 0x2098
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0 0x209c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2 0x20a4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0 0x20a8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2 0x20b0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK 0x20b4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK 0x20b8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK 0x20bc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK 0x20c4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK 0x20c8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK 0x20cc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK 0x20d0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK 0x20d4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK 0x20d8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK 0x20dc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK 0x20e0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK 0x20e4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK 0x20e8
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S1 0x3000
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S2 0x3004
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S3 0x3008
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S4 0x300c
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S5 0x3010
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S6 0x3014
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S7 0x3018
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S8 0x301c
+#define PCH_CON_LHM_AXI_P_PERIC0_PCH 0x3020
+#define QCH_CON_D_TZPC_PERIC0_QCH 0x3024
+#define QCH_CON_GPC_PERIC0_QCH 0x3028
+#define QCH_CON_GPIO_PERIC0_QCH 0x302c
+#define QCH_CON_LHM_AXI_P_PERIC0_QCH 0x3030
+#define QCH_CON_PERIC0_CMU_PERIC0_QCH 0x3034
+#define QCH_CON_PERIC0_TOP0_QCH_I3C1 0x3038
+#define QCH_CON_PERIC0_TOP0_QCH_I3C2 0x303c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C3 0x3040
+#define QCH_CON_PERIC0_TOP0_QCH_I3C4 0x3044
+#define QCH_CON_PERIC0_TOP0_QCH_I3C5 0x3048
+#define QCH_CON_PERIC0_TOP0_QCH_I3C6 0x304c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C7 0x3050
+#define QCH_CON_PERIC0_TOP0_QCH_I3C8 0x3054
+#define QCH_CON_PERIC0_TOP0_QCH_USI1_USI 0x3058
+#define QCH_CON_PERIC0_TOP0_QCH_USI2_USI 0x305c
+#define QCH_CON_PERIC0_TOP0_QCH_USI3_USI 0x3060
+#define QCH_CON_PERIC0_TOP0_QCH_USI4_USI 0x3064
+#define QCH_CON_PERIC0_TOP0_QCH_USI5_USI 0x3068
+#define QCH_CON_PERIC0_TOP0_QCH_USI6_USI 0x306c
+#define QCH_CON_PERIC0_TOP0_QCH_USI7_USI 0x3070
+#define QCH_CON_PERIC0_TOP0_QCH_USI8_USI 0x3074
+#define QCH_CON_PERIC0_TOP1_QCH_USI0_UART 0x3078
+#define QCH_CON_PERIC0_TOP1_QCH_USI14_UART 0x307c
+#define QCH_CON_SYSREG_PERIC0_QCH 0x3080
+#define QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0 0x3c00
+
+static const unsigned long peric0_clk_regs[] __initconst = {
+ PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+ PERIC0_CMU_PERIC0_CONTROLLER_OPTION,
+ CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0,
+ CLK_CON_DIV_DIV_CLK_PERIC0_I3C,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI,
+ CLK_CON_BUF_CLKBUF_PERIC0_IP,
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S1,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S2,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S3,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S4,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S5,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S6,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S7,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S8,
+ PCH_CON_LHM_AXI_P_PERIC0_PCH,
+ QCH_CON_D_TZPC_PERIC0_QCH,
+ QCH_CON_GPC_PERIC0_QCH,
+ QCH_CON_GPIO_PERIC0_QCH,
+ QCH_CON_LHM_AXI_P_PERIC0_QCH,
+ QCH_CON_PERIC0_CMU_PERIC0_QCH,
+ QCH_CON_PERIC0_TOP0_QCH_I3C1,
+ QCH_CON_PERIC0_TOP0_QCH_I3C2,
+ QCH_CON_PERIC0_TOP0_QCH_I3C3,
+ QCH_CON_PERIC0_TOP0_QCH_I3C4,
+ QCH_CON_PERIC0_TOP0_QCH_I3C5,
+ QCH_CON_PERIC0_TOP0_QCH_I3C6,
+ QCH_CON_PERIC0_TOP0_QCH_I3C7,
+ QCH_CON_PERIC0_TOP0_QCH_I3C8,
+ QCH_CON_PERIC0_TOP0_QCH_USI1_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI2_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI3_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI4_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI5_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI6_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI7_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI8_USI,
+ QCH_CON_PERIC0_TOP1_QCH_USI0_UART,
+ QCH_CON_PERIC0_TOP1_QCH_USI14_UART,
+ QCH_CON_SYSREG_PERIC0_QCH,
+ QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0,
+};
+
+/* List of parent clocks for Muxes in CMU_PERIC0 */
+PNAME(mout_peric0_bus_user_p) = { "oscclk", "dout_cmu_peric0_bus" };
+PNAME(mout_peric0_i3c_user_p) = { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi0_uart_user_p) = { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi_usi_user_p) = { "oscclk", "dout_cmu_peric0_ip" };
+
+static const struct samsung_mux_clock peric0_mux_clks[] __initconst = {
+ MUX(CLK_MOUT_PERIC0_BUS_USER, "mout_peric0_bus_user",
+ mout_peric0_bus_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_I3C_USER, "mout_peric0_i3c_user",
+ mout_peric0_i3c_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI0_UART_USER,
+ "mout_peric0_usi0_uart_user", mout_peric0_usi0_uart_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI14_USI_USER,
+ "mout_peric0_usi14_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI1_USI_USER,
+ "mout_peric0_usi1_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI2_USI_USER,
+ "mout_peric0_usi2_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI3_USI_USER,
+ "mout_peric0_usi3_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI4_USI_USER,
+ "mout_peric0_usi4_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI5_USI_USER,
+ "mout_peric0_usi5_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI6_USI_USER,
+ "mout_peric0_usi6_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI7_USI_USER,
+ "mout_peric0_usi7_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI8_USI_USER,
+ "mout_peric0_usi8_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER, 4, 1),
+};
+
+static const struct samsung_div_clock peric0_div_clks[] __initconst = {
+ DIV(CLK_DOUT_PERIC0_I3C, "dout_peric0_i3c", "mout_peric0_i3c_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_I3C, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI0_UART,
+ "dout_peric0_usi0_uart", "mout_peric0_usi0_uart_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI14_USI,
+ "dout_peric0_usi14_usi", "mout_peric0_usi14_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI1_USI,
+ "dout_peric0_usi1_usi", "mout_peric0_usi1_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI2_USI,
+ "dout_peric0_usi2_usi", "mout_peric0_usi2_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI3_USI,
+ "dout_peric0_usi3_usi", "mout_peric0_usi3_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI4_USI,
+ "dout_peric0_usi4_usi", "mout_peric0_usi4_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI5_USI,
+ "dout_peric0_usi5_usi", "mout_peric0_usi5_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI6_USI,
+ "dout_peric0_usi6_usi", "mout_peric0_usi6_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI7_USI,
+ "dout_peric0_usi7_usi", "mout_peric0_usi7_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI8_USI,
+ "dout_peric0_usi8_usi", "mout_peric0_usi8_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI, 0, 3),
+};
+
+static const struct samsung_gate_clock peric0_gate_clks[] __initconst = {
+ GATE(CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK,
+ "gout_peric0_peric0_cmu_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK,
+ "gout_peric0_clk_peric0_oscclk_clk", "oscclk",
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK,
+ "gout_peric0_d_tzpc_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_GPC_PERIC0_PCLK,
+ "gout_peric0_gpc_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK,
+ "gout_peric0_gpio_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK,
+ "gout_peric0_lhm_axi_p_peric0_i_clk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0,
+ "gout_peric0_peric0_top0_ipclk_0", "dout_peric0_usi1_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1,
+ "gout_peric0_peric0_top0_ipclk_1", "dout_peric0_usi2_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10,
+ "gout_peric0_peric0_top0_ipclk_10", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11,
+ "gout_peric0_peric0_top0_ipclk_11", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12,
+ "gout_peric0_peric0_top0_ipclk_12", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13,
+ "gout_peric0_peric0_top0_ipclk_13", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14,
+ "gout_peric0_peric0_top0_ipclk_14", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15,
+ "gout_peric0_peric0_top0_ipclk_15", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2,
+ "gout_peric0_peric0_top0_ipclk_2", "dout_peric0_usi3_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3,
+ "gout_peric0_peric0_top0_ipclk_3", "dout_peric0_usi4_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4,
+ "gout_peric0_peric0_top0_ipclk_4", "dout_peric0_usi5_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5,
+ "gout_peric0_peric0_top0_ipclk_5", "dout_peric0_usi6_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6,
+ "gout_peric0_peric0_top0_ipclk_6", "dout_peric0_usi7_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7,
+ "gout_peric0_peric0_top0_ipclk_7", "dout_peric0_usi8_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8,
+ "gout_peric0_peric0_top0_ipclk_8", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9,
+ "gout_peric0_peric0_top0_ipclk_9", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0,
+ "gout_peric0_peric0_top0_pclk_0", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1,
+ "gout_peric0_peric0_top0_pclk_1", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10,
+ "gout_peric0_peric0_top0_pclk_10", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11,
+ "gout_peric0_peric0_top0_pclk_11", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12,
+ "gout_peric0_peric0_top0_pclk_12", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13,
+ "gout_peric0_peric0_top0_pclk_13", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14,
+ "gout_peric0_peric0_top0_pclk_14", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15,
+ "gout_peric0_peric0_top0_pclk_15", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2,
+ "gout_peric0_peric0_top0_pclk_2", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3,
+ "gout_peric0_peric0_top0_pclk_3", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4,
+ "gout_peric0_peric0_top0_pclk_4", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5,
+ "gout_peric0_peric0_top0_pclk_5", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6,
+ "gout_peric0_peric0_top0_pclk_6", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7,
+ "gout_peric0_peric0_top0_pclk_7", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8,
+ "gout_peric0_peric0_top0_pclk_8", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9,
+ "gout_peric0_peric0_top0_pclk_9", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0,
+ "gout_peric0_peric0_top1_ipclk_0", "dout_peric0_usi0_uart",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2,
+ "gout_peric0_peric0_top1_ipclk_2", "dout_peric0_usi14_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0,
+ "gout_peric0_peric0_top1_pclk_0", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2,
+ "gout_peric0_peric0_top1_pclk_2", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK,
+ "gout_peric0_peric0_busp_clk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK,
+ "gout_peric0_clk_peric0_i3c_clk", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK,
+ "gout_peric0_clk_peric0_usi0_uart_clk", "dout_peric0_usi0_uart",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK,
+ "gout_peric0_clk_peric0_usi14_usi_clk", "dout_peric0_usi14_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK,
+ "gout_peric0_clk_peric0_usi1_usi_clk", "dout_peric0_usi1_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK,
+ "gout_peric0_clk_peric0_usi2_usi_clk", "dout_peric0_usi2_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK,
+ "gout_peric0_clk_peric0_usi3_usi_clk", "dout_peric0_usi3_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK,
+ "gout_peric0_clk_peric0_usi4_usi_clk", "dout_peric0_usi4_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK,
+ "gout_peric0_clk_peric0_usi5_usi_clk", "dout_peric0_usi5_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK,
+ "gout_peric0_clk_peric0_usi6_usi_clk", "dout_peric0_usi6_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK,
+ "gout_peric0_clk_peric0_usi7_usi_clk", "dout_peric0_usi7_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK,
+ "gout_peric0_clk_peric0_usi8_usi_clk", "dout_peric0_usi8_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK,
+ "gout_peric0_sysreg_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+};
+
+static const struct samsung_cmu_info peric0_cmu_info __initconst = {
+ .mux_clks = peric0_mux_clks,
+ .nr_mux_clks = ARRAY_SIZE(peric0_mux_clks),
+ .div_clks = peric0_div_clks,
+ .nr_div_clks = ARRAY_SIZE(peric0_div_clks),
+ .gate_clks = peric0_gate_clks,
+ .nr_gate_clks = ARRAY_SIZE(peric0_gate_clks),
+ .nr_clk_ids = CLKS_NR_PERIC0,
+ .clk_regs = peric0_clk_regs,
+ .nr_clk_regs = ARRAY_SIZE(peric0_clk_regs),
+ .clk_name = "dout_cmu_peric0_bus",
+};
+
/* ---- platform_driver ----------------------------------------------------- */
static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -2498,6 +3074,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
}, {
.compatible = "google,gs101-cmu-misc",
.data = &misc_cmu_info,
+ }, {
+ .compatible = "google,gs101-cmu-peric0",
+ .data = &peric0_cmu_info,
}, {
},
};
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 06/13] clk: samsung: gs101: add support for cmu_peric0
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
CMU_PERIC0 is the clock management unit used for the peric0 block which
is used for USI and I3C. Add support for cmu_peric0.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/clk/samsung/clk-gs101.c | 579 ++++++++++++++++++++++++++++++++
1 file changed, 579 insertions(+)
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 0964bb11657f..3d194520b05e 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -20,6 +20,7 @@
#define CLKS_NR_TOP (CLK_GOUT_CMU_TPU_UART + 1)
#define CLKS_NR_APM (CLK_APM_PLL_DIV16_APM + 1)
#define CLKS_NR_MISC (CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
+#define CLKS_NR_PERIC0 (CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK + 1)
/* ---- CMU_TOP ------------------------------------------------------------- */
@@ -2478,6 +2479,581 @@ static const struct samsung_cmu_info misc_cmu_info __initconst = {
.clk_name = "dout_cmu_misc_bus",
};
+/* ---- CMU_PERIC0 --------------------------------------------------------- */
+
+/* Register Offset definitions for CMU_PERIC0 (0x10800000) */
+#define PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER 0x0600
+#define PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER 0x0604
+#define PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER 0x0610
+#define PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER 0x0614
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER 0x0620
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER 0x0624
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER 0x0640
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER 0x0644
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER 0x0650
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER 0x0654
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER 0x0660
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER 0x0664
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER 0x0670
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER 0x0674
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER 0x0680
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER 0x0684
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER 0x0690
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER 0x0694
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER 0x06a0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER 0x06a4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER 0x06b0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER 0x06b4
+#define PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER 0x06c0
+#define PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER 0x06c4
+#define PERIC0_CMU_PERIC0_CONTROLLER_OPTION 0x0800
+#define CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0 0x0810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_I3C 0x1800
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART 0x1804
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI 0x180c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI 0x1810
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI 0x1814
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI 0x1820
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI 0x1824
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI 0x1828
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI 0x182c
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI 0x1830
+#define CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI 0x1834
+#define CLK_CON_BUF_CLKBUF_PERIC0_IP 0x2000
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK 0x2004
+#define CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK 0x2008
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK 0x200c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK 0x2010
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK 0x2014
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK 0x2018
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0 0x201c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1 0x2020
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10 0x2024
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11 0x2028
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12 0x202c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13 0x2030
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14 0x2034
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15 0x2038
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2 0x203c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3 0x2040
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4 0x2044
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5 0x2048
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6 0x204c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7 0x2050
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8 0x2054
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9 0x2058
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0 0x205c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1 0x2060
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10 0x2064
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11 0x2068
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12 0x206c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13 0x2070
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14 0x2074
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15 0x2078
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2 0x207c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3 0x2080
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4 0x2084
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5 0x2088
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6 0x208c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7 0x2090
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8 0x2094
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9 0x2098
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0 0x209c
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2 0x20a4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0 0x20a8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2 0x20b0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK 0x20b4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK 0x20b8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK 0x20bc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK 0x20c4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK 0x20c8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK 0x20cc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK 0x20d0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK 0x20d4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK 0x20d8
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK 0x20dc
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK 0x20e0
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK 0x20e4
+#define CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK 0x20e8
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S1 0x3000
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S2 0x3004
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S3 0x3008
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S4 0x300c
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S5 0x3010
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S6 0x3014
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S7 0x3018
+#define DMYQCH_CON_PERIC0_TOP0_QCH_S8 0x301c
+#define PCH_CON_LHM_AXI_P_PERIC0_PCH 0x3020
+#define QCH_CON_D_TZPC_PERIC0_QCH 0x3024
+#define QCH_CON_GPC_PERIC0_QCH 0x3028
+#define QCH_CON_GPIO_PERIC0_QCH 0x302c
+#define QCH_CON_LHM_AXI_P_PERIC0_QCH 0x3030
+#define QCH_CON_PERIC0_CMU_PERIC0_QCH 0x3034
+#define QCH_CON_PERIC0_TOP0_QCH_I3C1 0x3038
+#define QCH_CON_PERIC0_TOP0_QCH_I3C2 0x303c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C3 0x3040
+#define QCH_CON_PERIC0_TOP0_QCH_I3C4 0x3044
+#define QCH_CON_PERIC0_TOP0_QCH_I3C5 0x3048
+#define QCH_CON_PERIC0_TOP0_QCH_I3C6 0x304c
+#define QCH_CON_PERIC0_TOP0_QCH_I3C7 0x3050
+#define QCH_CON_PERIC0_TOP0_QCH_I3C8 0x3054
+#define QCH_CON_PERIC0_TOP0_QCH_USI1_USI 0x3058
+#define QCH_CON_PERIC0_TOP0_QCH_USI2_USI 0x305c
+#define QCH_CON_PERIC0_TOP0_QCH_USI3_USI 0x3060
+#define QCH_CON_PERIC0_TOP0_QCH_USI4_USI 0x3064
+#define QCH_CON_PERIC0_TOP0_QCH_USI5_USI 0x3068
+#define QCH_CON_PERIC0_TOP0_QCH_USI6_USI 0x306c
+#define QCH_CON_PERIC0_TOP0_QCH_USI7_USI 0x3070
+#define QCH_CON_PERIC0_TOP0_QCH_USI8_USI 0x3074
+#define QCH_CON_PERIC0_TOP1_QCH_USI0_UART 0x3078
+#define QCH_CON_PERIC0_TOP1_QCH_USI14_UART 0x307c
+#define QCH_CON_SYSREG_PERIC0_QCH 0x3080
+#define QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0 0x3c00
+
+static const unsigned long peric0_clk_regs[] __initconst = {
+ PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_BUS_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_I3C_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI0_UART_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI14_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI1_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI2_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI3_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI4_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI5_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI6_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI7_USI_USER,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+ PLL_CON1_MUX_CLKCMU_PERIC0_USI8_USI_USER,
+ PERIC0_CMU_PERIC0_CONTROLLER_OPTION,
+ CLKOUT_CON_BLK_PERIC0_CMU_PERIC0_CLKOUT0,
+ CLK_CON_DIV_DIV_CLK_PERIC0_I3C,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI,
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI,
+ CLK_CON_BUF_CLKBUF_PERIC0_IP,
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S1,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S2,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S3,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S4,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S5,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S6,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S7,
+ DMYQCH_CON_PERIC0_TOP0_QCH_S8,
+ PCH_CON_LHM_AXI_P_PERIC0_PCH,
+ QCH_CON_D_TZPC_PERIC0_QCH,
+ QCH_CON_GPC_PERIC0_QCH,
+ QCH_CON_GPIO_PERIC0_QCH,
+ QCH_CON_LHM_AXI_P_PERIC0_QCH,
+ QCH_CON_PERIC0_CMU_PERIC0_QCH,
+ QCH_CON_PERIC0_TOP0_QCH_I3C1,
+ QCH_CON_PERIC0_TOP0_QCH_I3C2,
+ QCH_CON_PERIC0_TOP0_QCH_I3C3,
+ QCH_CON_PERIC0_TOP0_QCH_I3C4,
+ QCH_CON_PERIC0_TOP0_QCH_I3C5,
+ QCH_CON_PERIC0_TOP0_QCH_I3C6,
+ QCH_CON_PERIC0_TOP0_QCH_I3C7,
+ QCH_CON_PERIC0_TOP0_QCH_I3C8,
+ QCH_CON_PERIC0_TOP0_QCH_USI1_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI2_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI3_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI4_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI5_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI6_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI7_USI,
+ QCH_CON_PERIC0_TOP0_QCH_USI8_USI,
+ QCH_CON_PERIC0_TOP1_QCH_USI0_UART,
+ QCH_CON_PERIC0_TOP1_QCH_USI14_UART,
+ QCH_CON_SYSREG_PERIC0_QCH,
+ QUEUE_CTRL_REG_BLK_PERIC0_CMU_PERIC0,
+};
+
+/* List of parent clocks for Muxes in CMU_PERIC0 */
+PNAME(mout_peric0_bus_user_p) = { "oscclk", "dout_cmu_peric0_bus" };
+PNAME(mout_peric0_i3c_user_p) = { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi0_uart_user_p) = { "oscclk", "dout_cmu_peric0_ip" };
+PNAME(mout_peric0_usi_usi_user_p) = { "oscclk", "dout_cmu_peric0_ip" };
+
+static const struct samsung_mux_clock peric0_mux_clks[] __initconst = {
+ MUX(CLK_MOUT_PERIC0_BUS_USER, "mout_peric0_bus_user",
+ mout_peric0_bus_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_BUS_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_I3C_USER, "mout_peric0_i3c_user",
+ mout_peric0_i3c_user_p, PLL_CON0_MUX_CLKCMU_PERIC0_I3C_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI0_UART_USER,
+ "mout_peric0_usi0_uart_user", mout_peric0_usi0_uart_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI0_UART_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI14_USI_USER,
+ "mout_peric0_usi14_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI14_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI1_USI_USER,
+ "mout_peric0_usi1_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI1_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI2_USI_USER,
+ "mout_peric0_usi2_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI2_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI3_USI_USER,
+ "mout_peric0_usi3_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI3_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI4_USI_USER,
+ "mout_peric0_usi4_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI4_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI5_USI_USER,
+ "mout_peric0_usi5_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI5_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI6_USI_USER,
+ "mout_peric0_usi6_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI6_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI7_USI_USER,
+ "mout_peric0_usi7_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI7_USI_USER, 4, 1),
+ MUX(CLK_MOUT_PERIC0_USI8_USI_USER,
+ "mout_peric0_usi8_usi_user", mout_peric0_usi_usi_user_p,
+ PLL_CON0_MUX_CLKCMU_PERIC0_USI8_USI_USER, 4, 1),
+};
+
+static const struct samsung_div_clock peric0_div_clks[] __initconst = {
+ DIV(CLK_DOUT_PERIC0_I3C, "dout_peric0_i3c", "mout_peric0_i3c_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_I3C, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI0_UART,
+ "dout_peric0_usi0_uart", "mout_peric0_usi0_uart_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI0_UART, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI14_USI,
+ "dout_peric0_usi14_usi", "mout_peric0_usi14_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI14_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI1_USI,
+ "dout_peric0_usi1_usi", "mout_peric0_usi1_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI1_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI2_USI,
+ "dout_peric0_usi2_usi", "mout_peric0_usi2_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI2_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI3_USI,
+ "dout_peric0_usi3_usi", "mout_peric0_usi3_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI3_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI4_USI,
+ "dout_peric0_usi4_usi", "mout_peric0_usi4_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI4_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI5_USI,
+ "dout_peric0_usi5_usi", "mout_peric0_usi5_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI5_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI6_USI,
+ "dout_peric0_usi6_usi", "mout_peric0_usi6_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI6_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI7_USI,
+ "dout_peric0_usi7_usi", "mout_peric0_usi7_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI7_USI, 0, 3),
+ DIV(CLK_DOUT_PERIC0_USI8_USI,
+ "dout_peric0_usi8_usi", "mout_peric0_usi8_usi_user",
+ CLK_CON_DIV_DIV_CLK_PERIC0_USI8_USI, 0, 3),
+};
+
+static const struct samsung_gate_clock peric0_gate_clks[] __initconst = {
+ GATE(CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK,
+ "gout_peric0_peric0_cmu_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_PERIC0_CMU_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK,
+ "gout_peric0_clk_peric0_oscclk_clk", "oscclk",
+ CLK_CON_GAT_CLK_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_OSCCLK_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK,
+ "gout_peric0_d_tzpc_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_D_TZPC_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_GPC_PERIC0_PCLK,
+ "gout_peric0_gpc_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPC_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK,
+ "gout_peric0_gpio_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_GPIO_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK,
+ "gout_peric0_lhm_axi_p_peric0_i_clk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_LHM_AXI_P_PERIC0_IPCLKPORT_I_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0,
+ "gout_peric0_peric0_top0_ipclk_0", "dout_peric0_usi1_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1,
+ "gout_peric0_peric0_top0_ipclk_1", "dout_peric0_usi2_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_1,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10,
+ "gout_peric0_peric0_top0_ipclk_10", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_10,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11,
+ "gout_peric0_peric0_top0_ipclk_11", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_11,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12,
+ "gout_peric0_peric0_top0_ipclk_12", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_12,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13,
+ "gout_peric0_peric0_top0_ipclk_13", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_13,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14,
+ "gout_peric0_peric0_top0_ipclk_14", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_14,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15,
+ "gout_peric0_peric0_top0_ipclk_15", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_15,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2,
+ "gout_peric0_peric0_top0_ipclk_2", "dout_peric0_usi3_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3,
+ "gout_peric0_peric0_top0_ipclk_3", "dout_peric0_usi4_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_3,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4,
+ "gout_peric0_peric0_top0_ipclk_4", "dout_peric0_usi5_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_4,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5,
+ "gout_peric0_peric0_top0_ipclk_5", "dout_peric0_usi6_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_5,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6,
+ "gout_peric0_peric0_top0_ipclk_6", "dout_peric0_usi7_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_6,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7,
+ "gout_peric0_peric0_top0_ipclk_7", "dout_peric0_usi8_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_7,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8,
+ "gout_peric0_peric0_top0_ipclk_8", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_8,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9,
+ "gout_peric0_peric0_top0_ipclk_9", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_IPCLK_9,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0,
+ "gout_peric0_peric0_top0_pclk_0", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1,
+ "gout_peric0_peric0_top0_pclk_1", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_1,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10,
+ "gout_peric0_peric0_top0_pclk_10", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_10,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11,
+ "gout_peric0_peric0_top0_pclk_11", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_11,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12,
+ "gout_peric0_peric0_top0_pclk_12", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_12,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13,
+ "gout_peric0_peric0_top0_pclk_13", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_13,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14,
+ "gout_peric0_peric0_top0_pclk_14", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_14,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15,
+ "gout_peric0_peric0_top0_pclk_15", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_15,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2,
+ "gout_peric0_peric0_top0_pclk_2", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3,
+ "gout_peric0_peric0_top0_pclk_3", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_3,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4,
+ "gout_peric0_peric0_top0_pclk_4", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_4,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5,
+ "gout_peric0_peric0_top0_pclk_5", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_5,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6,
+ "gout_peric0_peric0_top0_pclk_6", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_6,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7,
+ "gout_peric0_peric0_top0_pclk_7", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_7,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8,
+ "gout_peric0_peric0_top0_pclk_8", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_8,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9,
+ "gout_peric0_peric0_top0_pclk_9", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP0_IPCLKPORT_PCLK_9,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0,
+ "gout_peric0_peric0_top1_ipclk_0", "dout_peric0_usi0_uart",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2,
+ "gout_peric0_peric0_top1_ipclk_2", "dout_peric0_usi14_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_IPCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0,
+ "gout_peric0_peric0_top1_pclk_0", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_0,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2,
+ "gout_peric0_peric0_top1_pclk_2", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_PERIC0_TOP1_IPCLKPORT_PCLK_2,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK,
+ "gout_peric0_peric0_busp_clk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_BUSP_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK,
+ "gout_peric0_clk_peric0_i3c_clk", "dout_peric0_i3c",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_I3C_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK,
+ "gout_peric0_clk_peric0_usi0_uart_clk", "dout_peric0_usi0_uart",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI0_UART_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK,
+ "gout_peric0_clk_peric0_usi14_usi_clk", "dout_peric0_usi14_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI14_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK,
+ "gout_peric0_clk_peric0_usi1_usi_clk", "dout_peric0_usi1_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI1_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK,
+ "gout_peric0_clk_peric0_usi2_usi_clk", "dout_peric0_usi2_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI2_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK,
+ "gout_peric0_clk_peric0_usi3_usi_clk", "dout_peric0_usi3_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI3_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK,
+ "gout_peric0_clk_peric0_usi4_usi_clk", "dout_peric0_usi4_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI4_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK,
+ "gout_peric0_clk_peric0_usi5_usi_clk", "dout_peric0_usi5_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI5_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK,
+ "gout_peric0_clk_peric0_usi6_usi_clk", "dout_peric0_usi6_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI6_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK,
+ "gout_peric0_clk_peric0_usi7_usi_clk", "dout_peric0_usi7_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI7_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK,
+ "gout_peric0_clk_peric0_usi8_usi_clk", "dout_peric0_usi8_usi",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_RSTNSYNC_CLK_PERIC0_USI8_USI_IPCLKPORT_CLK,
+ 21, 0, 0),
+ GATE(CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK,
+ "gout_peric0_sysreg_peric0_pclk", "mout_peric0_bus_user",
+ CLK_CON_GAT_GOUT_BLK_PERIC0_UID_SYSREG_PERIC0_IPCLKPORT_PCLK,
+ 21, 0, 0),
+};
+
+static const struct samsung_cmu_info peric0_cmu_info __initconst = {
+ .mux_clks = peric0_mux_clks,
+ .nr_mux_clks = ARRAY_SIZE(peric0_mux_clks),
+ .div_clks = peric0_div_clks,
+ .nr_div_clks = ARRAY_SIZE(peric0_div_clks),
+ .gate_clks = peric0_gate_clks,
+ .nr_gate_clks = ARRAY_SIZE(peric0_gate_clks),
+ .nr_clk_ids = CLKS_NR_PERIC0,
+ .clk_regs = peric0_clk_regs,
+ .nr_clk_regs = ARRAY_SIZE(peric0_clk_regs),
+ .clk_name = "dout_cmu_peric0_bus",
+};
+
/* ---- platform_driver ----------------------------------------------------- */
static int __init gs101_cmu_probe(struct platform_device *pdev)
@@ -2498,6 +3074,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
}, {
.compatible = "google,gs101-cmu-misc",
.data = &misc_cmu_info,
+ }, {
+ .compatible = "google,gs101-cmu-peric0",
+ .data = &peric0_cmu_info,
}, {
},
};
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
which then makes the system hang. To prevent this, mark
CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
accordingly when tested.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/clk/samsung/clk-gs101.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 3d194520b05e..08d80fca9cd6 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
"mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
21, 0, 0),
GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
- CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
+ CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
"mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
21, 0, 0),
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
which then makes the system hang. To prevent this, mark
CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
accordingly when tested.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
drivers/clk/samsung/clk-gs101.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
index 3d194520b05e..08d80fca9cd6 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
"mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
21, 0, 0),
GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
- CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
+ CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
"mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
21, 0, 0),
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Enable the cmu-peric0 clock controller. It feeds USI and I3c.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 9747cb3fa03a..d0b0ad70c6ba 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
};
};
+ cmu_peric0: clock-controller@10800000 {
+ compatible = "google,gs101-cmu-peric0";
+ reg = <0x10800000 0x4000>;
+ #clock-cells = <1>;
+ clocks = <&ext_24_5m>,
+ <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
+ <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
+ clock-names = "oscclk",
+ "dout_cmu_peric0_bus",
+ "dout_cmu_peric0_ip";
+ };
+
sysreg_peric0: syscon@10820000 {
compatible = "google,gs101-peric0-sysreg", "syscon";
reg = <0x10820000 0x10000>;
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Enable the cmu-peric0 clock controller. It feeds USI and I3c.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 9747cb3fa03a..d0b0ad70c6ba 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
};
};
+ cmu_peric0: clock-controller@10800000 {
+ compatible = "google,gs101-cmu-peric0";
+ reg = <0x10800000 0x4000>;
+ #clock-cells = <1>;
+ clocks = <&ext_24_5m>,
+ <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
+ <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
+ clock-names = "oscclk",
+ "dout_cmu_peric0_bus",
+ "dout_cmu_peric0_ip";
+ };
+
sysreg_peric0: syscon@10820000 {
compatible = "google,gs101-peric0-sysreg", "syscon";
reg = <0x10820000 0x10000>;
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Get rid of the dummy clock and start using the cmu_peric0 clocks
for the usi_uart and serial_0 nodes.
Tested the serial at 115200, 1000000 and 3000000 baudrates,
everthing went fine.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index d0b0ad70c6ba..ffb7b4d89a8c 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
};
};
- /* TODO replace with CCF clock */
- dummy_clk: clock-3 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <12345>;
- clock-output-names = "pclk";
- };
-
/* ect node is required to be present by bootloader */
ect {
};
@@ -369,7 +361,8 @@ usi_uart: usi@10a000c0 {
ranges;
#address-cells = <1>;
#size-cells = <1>;
- clocks = <&dummy_clk>, <&dummy_clk>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+ <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
clock-names = "pclk", "ipclk";
samsung,sysreg = <&sysreg_peric0 0x1020>;
samsung,mode = <USI_V2_UART>;
@@ -381,7 +374,8 @@ serial_0: serial@10a00000 {
reg-io-width = <4>;
interrupts = <GIC_SPI 634
IRQ_TYPE_LEVEL_HIGH 0>;
- clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+ <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
clock-names = "uart", "clk_uart_baud0";
samsung,uart-fifosize = <256>;
status = "disabled";
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Get rid of the dummy clock and start using the cmu_peric0 clocks
for the usi_uart and serial_0 nodes.
Tested the serial at 115200, 1000000 and 3000000 baudrates,
everthing went fine.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index d0b0ad70c6ba..ffb7b4d89a8c 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
};
};
- /* TODO replace with CCF clock */
- dummy_clk: clock-3 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <12345>;
- clock-output-names = "pclk";
- };
-
/* ect node is required to be present by bootloader */
ect {
};
@@ -369,7 +361,8 @@ usi_uart: usi@10a000c0 {
ranges;
#address-cells = <1>;
#size-cells = <1>;
- clocks = <&dummy_clk>, <&dummy_clk>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+ <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
clock-names = "pclk", "ipclk";
samsung,sysreg = <&sysreg_peric0 0x1020>;
samsung,mode = <USI_V2_UART>;
@@ -381,7 +374,8 @@ serial_0: serial@10a00000 {
reg-io-width = <4>;
interrupts = <GIC_SPI 634
IRQ_TYPE_LEVEL_HIGH 0>;
- clocks = <&dummy_clk 0>, <&dummy_clk 0>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
+ <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
clock-names = "uart", "clk_uart_baud0";
samsung,uart-fifosize = <256>;
status = "disabled";
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
USI8 I2C is used to communicate with an eeprom found on the battery
connector. Define USI8 in I2C configuration.
USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
selection of the protocol is intentionally left for the board dtsi file.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index ffb7b4d89a8c..4ea1b180cd0a 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl@10840000 {
interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
};
+ usi8: usi@109700c0 {
+ compatible = "google,gs101-usi",
+ "samsung,exynos850-usi";
+ reg = <0x109700c0 0x20>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+ clock-names = "pclk", "ipclk";
+ samsung,sysreg = <&sysreg_peric0 0x101c>;
+ status = "disabled";
+
+ hsi2c_8: i2c@10970000 {
+ compatible = "google,gs101-hsi2c",
+ "samsung,exynosautov9-hsi2c";
+ reg = <0x10970000 0xc0>;
+ interrupts = <GIC_SPI 642
+ IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+ clock-names = "hsi2c", "hsi2c_pclk";
+ status = "disabled";
+ };
+ };
+
usi_uart: usi@10a000c0 {
compatible = "google,gs101-usi",
"samsung,exynos850-usi";
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
USI8 I2C is used to communicate with an eeprom found on the battery
connector. Define USI8 in I2C configuration.
USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
selection of the protocol is intentionally left for the board dtsi file.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index ffb7b4d89a8c..4ea1b180cd0a 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl@10840000 {
interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
};
+ usi8: usi@109700c0 {
+ compatible = "google,gs101-usi",
+ "samsung,exynos850-usi";
+ reg = <0x109700c0 0x20>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+ clock-names = "pclk", "ipclk";
+ samsung,sysreg = <&sysreg_peric0 0x101c>;
+ status = "disabled";
+
+ hsi2c_8: i2c@10970000 {
+ compatible = "google,gs101-hsi2c",
+ "samsung,exynosautov9-hsi2c";
+ reg = <0x10970000 0xc0>;
+ interrupts = <GIC_SPI 642
+ IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+ clock-names = "hsi2c", "hsi2c_pclk";
+ status = "disabled";
+ };
+ };
+
usi_uart: usi@10a000c0 {
compatible = "google,gs101-usi",
"samsung,exynos850-usi";
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Enable the eeprom found on the battery connector.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
.../boot/dts/exynos/google/gs101-oriole.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
index 4a71f752200d..11b299d21c5d 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -63,6 +63,19 @@ &ext_200m {
clock-frequency = <200000000>;
};
+&hsi2c_8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsi2c8_bus>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ };
+};
+
&pinctrl_far_alive {
key_voldown: key-voldown-pins {
samsung,pins = "gpa7-3";
@@ -99,6 +112,11 @@ &usi_uart {
status = "okay";
};
+&usi8 {
+ samsung,mode = <USI_V2_I2C>;
+ status = "okay";
+};
+
&watchdog_cl0 {
timeout-sec = <30>;
status = "okay";
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Enable the eeprom found on the battery connector.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
.../boot/dts/exynos/google/gs101-oriole.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
index 4a71f752200d..11b299d21c5d 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
+++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
@@ -63,6 +63,19 @@ &ext_200m {
clock-frequency = <200000000>;
};
+&hsi2c_8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsi2c8_bus>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ };
+};
+
&pinctrl_far_alive {
key_voldown: key-voldown-pins {
samsung,pins = "gpa7-3";
@@ -99,6 +112,11 @@ &usi_uart {
status = "okay";
};
+&usi8 {
+ samsung,mode = <USI_V2_I2C>;
+ status = "okay";
+};
+
&watchdog_cl0 {
timeout-sec = <30>;
status = "okay";
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 12/13] arm64: defconfig: sync with savedefconfig
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Sync the defconfig with savedefconfig as config options
change/move over time.
Generated with the following commands:
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
cp defconfig arch/arm64/configs/defconfig
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
1 file changed, 55 insertions(+), 89 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..09fb467303ba 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PROFILING=y
+CONFIG_KEXEC_FILE=y
+CONFIG_CRASH_DUMP=y
CONFIG_ARCH_ACTIONS=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_ALPINE=y
@@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_SMT=y
CONFIG_NUMA=y
-CONFIG_KEXEC=y
-CONFIG_KEXEC_FILE=y
-CONFIG_CRASH_DUMP=y
CONFIG_XEN=y
CONFIG_COMPAT=y
CONFIG_RANDOMIZE_BASE=y
@@ -119,7 +118,6 @@ CONFIG_KVM=y
CONFIG_JUMP_LABEL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-CONFIG_IOSCHED_BFQ=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_COMPAT_BRK is not set
CONFIG_MEMORY_HOTPLUG=y
@@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_NET=y
CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
@@ -180,8 +176,6 @@ CONFIG_NET_ACT_GATE=m
CONFIG_QRTR_SMD=m
CONFIG_QRTR_TUN=m
CONFIG_CAN=m
-CONFIG_CAN_M_CAN=m
-CONFIG_CAN_M_CAN_PLATFORM=m
CONFIG_BT=m
CONFIG_BT_HIDP=m
# CONFIG_BT_LE is not set
@@ -215,27 +209,27 @@ CONFIG_PCI_PASID=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PCI_AARDVARK=y
-CONFIG_PCI_TEGRA=y
-CONFIG_PCIE_RCAR_HOST=y
-CONFIG_PCIE_RCAR_EP=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_XGENE=y
CONFIG_PCIE_ALTERA=y
CONFIG_PCIE_ALTERA_MSI=y
+CONFIG_PCIE_BRCMSTB=m
CONFIG_PCI_HOST_THUNDER_PEM=y
CONFIG_PCI_HOST_THUNDER_ECAM=y
-CONFIG_PCIE_ROCKCHIP_HOST=m
+CONFIG_PCI_HOST_GENERIC=y
CONFIG_PCIE_MEDIATEK_GEN3=m
-CONFIG_PCIE_BRCMSTB=m
+CONFIG_PCI_TEGRA=y
+CONFIG_PCIE_RCAR_HOST=y
+CONFIG_PCIE_RCAR_EP=y
+CONFIG_PCIE_ROCKCHIP_HOST=m
+CONFIG_PCI_XGENE=y
CONFIG_PCI_IMX6_HOST=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
-CONFIG_PCIE_QCOM=y
-CONFIG_PCIE_ARMADA_8K=y
-CONFIG_PCIE_ROCKCHIP_DW_HOST=y
CONFIG_PCIE_KIRIN=y
CONFIG_PCIE_HISI_STB=y
+CONFIG_PCIE_ARMADA_8K=y
CONFIG_PCIE_TEGRA194_HOST=m
+CONFIG_PCIE_QCOM=y
+CONFIG_PCIE_ROCKCHIP_DW_HOST=y
CONFIG_PCIE_VISCONTI_HOST=y
CONFIG_PCIE_LAYERSCAPE_GEN4=y
CONFIG_PCI_ENDPOINT=y
@@ -247,14 +241,12 @@ CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_HISILICON_LPC=y
CONFIG_TEGRA_ACONNECT=m
CONFIG_MHI_BUS_PCI_GENERIC=m
-CONFIG_ARM_SCMI_PROTOCOL=y
CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_INTEL_STRATIX10_SERVICE=y
CONFIG_INTEL_STRATIX10_RSU=m
CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_IMX_SCU=y
-CONFIG_IMX_SCU_PD=y
CONFIG_GNSS=m
CONFIG_GNSS_MTK_SERIAL=m
CONFIG_MTD=y
@@ -276,15 +268,12 @@ CONFIG_MTD_NAND_FSL_IFC=y
CONFIG_MTD_NAND_QCOM=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=m
-CONFIG_UBIFS_FS=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
CONFIG_BLK_DEV_NVME=m
CONFIG_QCOM_COINCELL=m
CONFIG_QCOM_FASTRPC=m
-CONFIG_BATTERY_QCOM_BATTMGR=m
-CONFIG_UCSI_PMIC_GLINK=m
CONFIG_SRAM=y
CONFIG_PCI_ENDPOINT_TEST=m
CONFIG_EEPROM_AT24=m
@@ -308,7 +297,6 @@ CONFIG_AHCI_XGENE=y
CONFIG_AHCI_QORIQ=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_RCAR=y
-CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
@@ -384,6 +372,8 @@ CONFIG_DP83869_PHY=m
CONFIG_DP83TD510_PHY=y
CONFIG_VITESSE_PHY=y
CONFIG_CAN_FLEXCAN=m
+CONFIG_CAN_M_CAN=m
+CONFIG_CAN_M_CAN_PLATFORM=m
CONFIG_CAN_RCAR=m
CONFIG_CAN_RCAR_CANFD=m
CONFIG_CAN_MCP251XFD=m
@@ -574,9 +564,9 @@ CONFIG_PINCTRL_IMX8DXL=y
CONFIG_PINCTRL_IMX8ULP=y
CONFIG_PINCTRL_IMX93=y
CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_IPQ8074=y
CONFIG_PINCTRL_IPQ5018=y
CONFIG_PINCTRL_IPQ5332=y
+CONFIG_PINCTRL_IPQ8074=y
CONFIG_PINCTRL_IPQ6018=y
CONFIG_PINCTRL_IPQ9574=y
CONFIG_PINCTRL_MSM8916=y
@@ -588,34 +578,33 @@ CONFIG_PINCTRL_MSM8998=y
CONFIG_PINCTRL_QCM2290=y
CONFIG_PINCTRL_QCS404=y
CONFIG_PINCTRL_QDF2XXX=y
-CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QDU1000=y
CONFIG_PINCTRL_SA8775P=y
CONFIG_PINCTRL_SC7180=y
CONFIG_PINCTRL_SC7280=y
-CONFIG_PINCTRL_SC7280_LPASS_LPI=m
CONFIG_PINCTRL_SC8180X=y
CONFIG_PINCTRL_SC8280XP=y
CONFIG_PINCTRL_SDM660=y
CONFIG_PINCTRL_SDM670=y
CONFIG_PINCTRL_SDM845=y
CONFIG_PINCTRL_SM6115=y
-CONFIG_PINCTRL_SM6115_LPASS_LPI=m
CONFIG_PINCTRL_SM6125=y
CONFIG_PINCTRL_SM6350=y
CONFIG_PINCTRL_SM6375=y
CONFIG_PINCTRL_SM8150=y
CONFIG_PINCTRL_SM8250=y
-CONFIG_PINCTRL_SM8250_LPASS_LPI=m
CONFIG_PINCTRL_SM8350=y
-CONFIG_PINCTRL_SM8350_LPASS_LPI=m
CONFIG_PINCTRL_SM8450=y
+CONFIG_PINCTRL_SM8550=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_PINCTRL_LPASS_LPI=m
+CONFIG_PINCTRL_SC7280_LPASS_LPI=m
+CONFIG_PINCTRL_SM6115_LPASS_LPI=m
+CONFIG_PINCTRL_SM8250_LPASS_LPI=m
+CONFIG_PINCTRL_SM8350_LPASS_LPI=m
CONFIG_PINCTRL_SM8450_LPASS_LPI=m
CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
-CONFIG_PINCTRL_SM8550=y
CONFIG_PINCTRL_SM8550_LPASS_LPI=m
-CONFIG_PINCTRL_LPASS_LPI=m
-CONFIG_GPIO_AGGREGATOR=m
CONFIG_GPIO_ALTERA=m
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
@@ -624,6 +613,7 @@ CONFIG_GPIO_MPC8XXX=y
CONFIG_GPIO_MXC=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_RCAR=y
+CONFIG_GPIO_SYSCON=y
CONFIG_GPIO_UNIPHIER=y
CONFIG_GPIO_VISCONTI=y
CONFIG_GPIO_WCD934X=m
@@ -635,7 +625,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_BD9571MWV=m
CONFIG_GPIO_MAX77620=y
CONFIG_GPIO_SL28CPLD=m
-CONFIG_GPIO_SYSCON=y
+CONFIG_GPIO_AGGREGATOR=m
CONFIG_POWER_RESET_MSM=y
CONFIG_POWER_RESET_QCOM_PON=m
CONFIG_POWER_RESET_XGENE=y
@@ -643,6 +633,7 @@ CONFIG_POWER_RESET_SYSCON=y
CONFIG_POWER_RESET_SYSCON_POWEROFF=y
CONFIG_SYSCON_REBOOT_MODE=y
CONFIG_NVMEM_REBOOT_MODE=m
+CONFIG_BATTERY_QCOM_BATTMGR=m
CONFIG_BATTERY_SBS=m
CONFIG_BATTERY_BQ27XXX=y
CONFIG_BATTERY_MAX17042=m
@@ -667,8 +658,8 @@ CONFIG_DEVFREQ_THERMAL=y
CONFIG_THERMAL_EMULATION=y
CONFIG_IMX_SC_THERMAL=m
CONFIG_IMX8MM_THERMAL=m
-CONFIG_QORIQ_THERMAL=m
CONFIG_K3_THERMAL=m
+CONFIG_QORIQ_THERMAL=m
CONFIG_SUN8I_THERMAL=y
CONFIG_ROCKCHIP_THERMAL=m
CONFIG_RCAR_THERMAL=y
@@ -694,6 +685,7 @@ CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_ARM_SBSA_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_DW_WATCHDOG=y
+CONFIG_K3_RTI_WATCHDOG=m
CONFIG_SUNXI_WATCHDOG=m
CONFIG_NPCM7XX_WATCHDOG=y
CONFIG_IMX2_WDT=y
@@ -709,7 +701,6 @@ CONFIG_UNIPHIER_WATCHDOG=y
CONFIG_PM8916_WATCHDOG=m
CONFIG_BCM2835_WDT=y
CONFIG_BCM7038_WDT=m
-CONFIG_K3_RTI_WATCHDOG=m
CONFIG_MFD_ALTERA_SYSMGR=y
CONFIG_MFD_BD9571MWV=y
CONFIG_MFD_AXP20X_I2C=y
@@ -726,9 +717,9 @@ CONFIG_MFD_RK8XX_SPI=y
CONFIG_MFD_SEC_CORE=y
CONFIG_MFD_SL28CPLD=y
CONFIG_RZ_MTU3=y
+CONFIG_MFD_TI_AM335X_TSCADC=m
CONFIG_MFD_TPS65219=y
CONFIG_MFD_TPS6594_I2C=m
-CONFIG_MFD_TI_AM335X_TSCADC=m
CONFIG_MFD_ROHM_BD718XX=y
CONFIG_MFD_WCD934X=m
CONFIG_MFD_KHADAS_MCU=m
@@ -832,12 +823,8 @@ CONFIG_ROCKCHIP_INNO_HDMI=y
CONFIG_ROCKCHIP_LVDS=y
CONFIG_DRM_RCAR_DU=m
CONFIG_DRM_RCAR_DW_HDMI=m
-CONFIG_DRM_RCAR_MIPI_DSI=m
CONFIG_DRM_RZG2L_MIPI_DSI=m
CONFIG_DRM_SUN4I=m
-CONFIG_DRM_SUN6I_DSI=m
-CONFIG_DRM_SUN8I_DW_HDMI=m
-CONFIG_DRM_SUN8I_MIXER=m
CONFIG_DRM_MSM=m
CONFIG_DRM_TEGRA=m
CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
@@ -856,7 +843,6 @@ CONFIG_DRM_LONTIUM_LT9611UXC=m
CONFIG_DRM_ITE_IT66121=m
CONFIG_DRM_NWL_MIPI_DSI=m
CONFIG_DRM_PARADE_PS8640=m
-CONFIG_DRM_SAMSUNG_DSIM=m
CONFIG_DRM_SII902X=m
CONFIG_DRM_SIMPLE_BRIDGE=m
CONFIG_DRM_THINE_THC63LVD1024=m
@@ -879,15 +865,15 @@ CONFIG_DRM_HISI_KIRIN=m
CONFIG_DRM_MEDIATEK=m
CONFIG_DRM_MEDIATEK_HDMI=m
CONFIG_DRM_MXSFB=m
-CONFIG_DRM_MESON=m
CONFIG_DRM_IMX_LCDIF=m
+CONFIG_DRM_MESON=m
CONFIG_DRM_PL111=m
CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
CONFIG_DRM_TIDSS=m
CONFIG_FB=y
-CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_EFI=y
+CONFIG_FB_MODE_HELPERS=y
CONFIG_BACKLIGHT_PWM=m
CONFIG_BACKLIGHT_LP855X=m
CONFIG_LOGO=y
@@ -949,7 +935,7 @@ CONFIG_SND_SOC_TEGRA210_AMX=m
CONFIG_SND_SOC_TEGRA210_ADX=m
CONFIG_SND_SOC_TEGRA210_MIXER=m
CONFIG_SND_SOC_TEGRA_AUDIO_GRAPH_CARD=m
-CONFIG_SND_SOC_DAVINCI_MCASP=m
+CONFIG_SND_SOC_J721E_EVM=m
CONFIG_SND_SOC_AK4613=m
CONFIG_SND_SOC_DA7213=m
CONFIG_SND_SOC_ES7134=m
@@ -958,10 +944,8 @@ CONFIG_SND_SOC_ES8316=m
CONFIG_SND_SOC_GTM601=m
CONFIG_SND_SOC_MSM8916_WCD_ANALOG=m
CONFIG_SND_SOC_MSM8916_WCD_DIGITAL=m
-CONFIG_SND_SOC_PCM3168A_I2C=m
CONFIG_SND_SOC_RK817=m
CONFIG_SND_SOC_RT5640=m
-CONFIG_SND_SOC_J721E_EVM=m
CONFIG_SND_SOC_RT5659=m
CONFIG_SND_SOC_SIMPLE_AMPLIFIER=m
CONFIG_SND_SOC_SIMPLE_MUX=m
@@ -980,8 +964,6 @@ CONFIG_SND_SOC_WSA881X=m
CONFIG_SND_SOC_NAU8822=m
CONFIG_SND_SOC_LPASS_WSA_MACRO=m
CONFIG_SND_SOC_LPASS_VA_MACRO=m
-CONFIG_SND_SOC_LPASS_RX_MACRO=m
-CONFIG_SND_SOC_LPASS_TX_MACRO=m
CONFIG_SND_SIMPLE_CARD=m
CONFIG_SND_AUDIO_GRAPH_CARD=m
CONFIG_SND_AUDIO_GRAPH_CARD2=m
@@ -1047,14 +1029,15 @@ CONFIG_TYPEC=m
CONFIG_TYPEC_TCPM=m
CONFIG_TYPEC_TCPCI=m
CONFIG_TYPEC_FUSB302=m
-CONFIG_TYPEC_TPS6598X=m
-CONFIG_TYPEC_HD3SS3220=m
CONFIG_TYPEC_QCOM_PMIC=m
CONFIG_TYPEC_UCSI=m
-CONFIG_TYPEC_MUX_FSA4480=m
-CONFIG_TYPEC_MUX_NB7VPQ904M=m
CONFIG_UCSI_CCG=m
+CONFIG_UCSI_PMIC_GLINK=m
+CONFIG_TYPEC_TPS6598X=m
+CONFIG_TYPEC_HD3SS3220=m
+CONFIG_TYPEC_MUX_FSA4480=m
CONFIG_TYPEC_MUX_GPIO_SBU=m
+CONFIG_TYPEC_MUX_NB7VPQ904M=m
CONFIG_TYPEC_DP_ALTMODE=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=32
@@ -1185,7 +1168,6 @@ CONFIG_CROS_EC_RPMSG=m
CONFIG_CROS_EC_SPI=y
CONFIG_CROS_EC_CHARDEV=m
CONFIG_COMMON_CLK_RK808=y
-CONFIG_COMMON_CLK_SCMI=y
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_FSL_SAI=y
@@ -1203,18 +1185,6 @@ CONFIG_CLK_IMX8QXP=y
CONFIG_CLK_IMX8ULP=y
CONFIG_CLK_IMX93=y
CONFIG_TI_SCI_CLK=y
-CONFIG_COMMON_CLK_MT8192_AUDSYS=y
-CONFIG_COMMON_CLK_MT8192_CAMSYS=y
-CONFIG_COMMON_CLK_MT8192_IMGSYS=y
-CONFIG_COMMON_CLK_MT8192_IMP_IIC_WRAP=y
-CONFIG_COMMON_CLK_MT8192_IPESYS=y
-CONFIG_COMMON_CLK_MT8192_MDPSYS=y
-CONFIG_COMMON_CLK_MT8192_MFGCFG=y
-CONFIG_COMMON_CLK_MT8192_MMSYS=y
-CONFIG_COMMON_CLK_MT8192_MSDC=y
-CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
-CONFIG_COMMON_CLK_MT8192_VDECSYS=y
-CONFIG_COMMON_CLK_MT8192_VENCSYS=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_QCOM_A53PLL=y
CONFIG_QCOM_CLK_APCS_MSM8916=y
@@ -1222,24 +1192,23 @@ CONFIG_QCOM_CLK_APCC_MSM8996=y
CONFIG_QCOM_CLK_SMD_RPM=y
CONFIG_QCOM_CLK_RPMH=y
CONFIG_IPQ_APSS_6018=y
-CONFIG_IPQ_GCC_5332=y
-CONFIG_IPQ_APSS_5018=y
CONFIG_IPQ_GCC_5018=y
+CONFIG_IPQ_GCC_5332=y
CONFIG_IPQ_GCC_6018=y
CONFIG_IPQ_GCC_8074=y
CONFIG_IPQ_GCC_9574=y
CONFIG_MSM_GCC_8916=y
+CONFIG_MSM_MMCC_8994=m
CONFIG_MSM_GCC_8994=y
CONFIG_MSM_GCC_8996=y
-CONFIG_MSM_MMCC_8994=m
CONFIG_MSM_MMCC_8996=m
-CONFIG_MSM_MMCC_8998=m
CONFIG_MSM_GCC_8998=y
+CONFIG_MSM_MMCC_8998=m
CONFIG_QCM_GCC_2290=y
CONFIG_QCM_DISPCC_2290=m
CONFIG_QCS_GCC_404=y
-CONFIG_SA_GCC_8775P=y
CONFIG_SC_DISPCC_8280XP=m
+CONFIG_SA_GCC_8775P=y
CONFIG_SA_GPUCC_8775P=m
CONFIG_SC_GCC_7180=y
CONFIG_SC_GCC_7280=y
@@ -1261,10 +1230,10 @@ CONFIG_SM_GCC_6115=y
CONFIG_SM_GCC_8350=y
CONFIG_SM_GCC_8450=y
CONFIG_SM_GCC_8550=y
-CONFIG_SM_TCSRCC_8550=y
CONFIG_SM_GPUCC_6115=m
CONFIG_SM_GPUCC_8150=y
CONFIG_SM_GPUCC_8250=y
+CONFIG_SM_TCSRCC_8550=y
CONFIG_SM_VIDEOCC_8250=y
CONFIG_QCOM_HFPLL=y
CONFIG_CLK_GFM_LPASS_SM8250=m
@@ -1275,7 +1244,6 @@ CONFIG_TEGRA186_TIMER=y
CONFIG_RENESAS_OSTM=y
CONFIG_ARM_MHU=y
CONFIG_IMX_MBOX=y
-CONFIG_OMAP2PLUS_MBOX=m
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
CONFIG_QCOM_APCS_IPC=y
@@ -1288,14 +1256,14 @@ CONFIG_MTK_IOMMU=y
CONFIG_QCOM_IOMMU=y
CONFIG_REMOTEPROC=y
CONFIG_IMX_REMOTEPROC=y
-CONFIG_TI_K3_R5_REMOTEPROC=m
-CONFIG_TI_K3_DSP_REMOTEPROC=m
CONFIG_MTK_SCP=m
CONFIG_QCOM_Q6V5_ADSP=m
CONFIG_QCOM_Q6V5_MSS=m
CONFIG_QCOM_Q6V5_PAS=m
CONFIG_QCOM_SYSMON=m
CONFIG_QCOM_WCNSS_PIL=m
+CONFIG_TI_K3_DSP_REMOTEPROC=m
+CONFIG_TI_K3_R5_REMOTEPROC=m
CONFIG_RPMSG_CHAR=m
CONFIG_RPMSG_CTRL=m
CONFIG_RPMSG_QCOM_GLINK_RPM=y
@@ -1304,8 +1272,6 @@ CONFIG_RPMSG_QCOM_SMD=y
CONFIG_RPMSG_VIRTIO=y
CONFIG_SOUNDWIRE=m
CONFIG_SOUNDWIRE_QCOM=m
-CONFIG_OWL_PM_DOMAINS=y
-CONFIG_RASPBERRYPI_POWER=y
CONFIG_FSL_DPAA=y
CONFIG_FSL_MC_DPIO=y
CONFIG_FSL_RCPM=y
@@ -1315,15 +1281,12 @@ CONFIG_MTK_PMIC_WRAP=y
CONFIG_MTK_SVS=m
CONFIG_QCOM_AOSS_QMP=y
CONFIG_QCOM_COMMAND_DB=y
-CONFIG_QCOM_CPR=y
CONFIG_QCOM_GENI_SE=y
CONFIG_QCOM_LLCC=m
CONFIG_QCOM_OCMEM=m
CONFIG_QCOM_PMIC_GLINK=m
CONFIG_QCOM_RMTFS_MEM=m
CONFIG_QCOM_RPMH=y
-CONFIG_QCOM_RPMHPD=y
-CONFIG_QCOM_RPMPD=y
CONFIG_QCOM_SMEM=y
CONFIG_QCOM_SMD_RPM=y
CONFIG_QCOM_SMP2P=y
@@ -1355,14 +1318,20 @@ CONFIG_ARCH_R9A07G054=y
CONFIG_ARCH_R9A08G045=y
CONFIG_ARCH_R9A09G011=y
CONFIG_ROCKCHIP_IODOMAIN=y
-CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_ARCH_TEGRA_132_SOC=y
CONFIG_ARCH_TEGRA_210_SOC=y
CONFIG_ARCH_TEGRA_186_SOC=y
CONFIG_ARCH_TEGRA_194_SOC=y
CONFIG_ARCH_TEGRA_234_SOC=y
-CONFIG_TI_SCI_PM_DOMAINS=y
CONFIG_TI_PRUSS=m
+CONFIG_OWL_PM_DOMAINS=y
+CONFIG_RASPBERRYPI_POWER=y
+CONFIG_IMX_SCU_PD=y
+CONFIG_QCOM_CPR=y
+CONFIG_QCOM_RPMHPD=y
+CONFIG_QCOM_RPMPD=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+CONFIG_TI_SCI_PM_DOMAINS=y
CONFIG_ARM_IMX_BUS_DEVFREQ=y
CONFIG_ARM_IMX8M_DDRC_DEVFREQ=m
CONFIG_ARM_MEDIATEK_CCI_DEVFREQ=m
@@ -1430,17 +1399,17 @@ CONFIG_PHY_HISI_INNO_USB2=y
CONFIG_PHY_MVEBU_CP110_COMPHY=y
CONFIG_PHY_MTK_TPHY=y
CONFIG_PHY_QCOM_EDP=m
-CONFIG_PHY_QCOM_EUSB2_REPEATER=m
CONFIG_PHY_QCOM_PCIE2=m
CONFIG_PHY_QCOM_QMP=m
CONFIG_PHY_QCOM_QUSB2=m
CONFIG_PHY_QCOM_SNPS_EUSB2=m
+CONFIG_PHY_QCOM_EUSB2_REPEATER=m
+CONFIG_PHY_QCOM_M31_USB=m
CONFIG_PHY_QCOM_USB_HS=m
CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=m
CONFIG_PHY_QCOM_USB_HS_28NM=m
CONFIG_PHY_QCOM_USB_SS=m
CONFIG_PHY_QCOM_SGMII_ETH=m
-CONFIG_PHY_QCOM_M31_USB=m
CONFIG_PHY_R8A779F0_ETHERNET_SERDES=y
CONFIG_PHY_RCAR_GEN3_PCIE=y
CONFIG_PHY_RCAR_GEN3_USB2=y
@@ -1462,7 +1431,6 @@ CONFIG_PHY_J721E_WIZ=m
CONFIG_ARM_CCI_PMU=m
CONFIG_ARM_CCN=m
CONFIG_ARM_CMN=m
-CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
CONFIG_ARM_SMMU_V3_PMU=m
CONFIG_ARM_DSU_PMU=m
CONFIG_FSL_IMX8_DDR_PMU=m
@@ -1471,6 +1439,7 @@ CONFIG_QCOM_L3_PMU=y
CONFIG_ARM_SPE_PMU=m
CONFIG_ARM_DMC620_PMU=m
CONFIG_HISI_PMU=y
+CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
CONFIG_MESON_DDR_PMU=m
CONFIG_NVMEM_LAYOUT_SL28_VPD=m
CONFIG_NVMEM_IMX_OCOTP=y
@@ -1498,10 +1467,8 @@ CONFIG_TEE=y
CONFIG_OPTEE=y
CONFIG_MUX_GPIO=m
CONFIG_MUX_MMIO=y
-CONFIG_SLIMBUS=m
CONFIG_SLIM_QCOM_CTRL=m
CONFIG_SLIM_QCOM_NGD_CTRL=m
-CONFIG_INTERCONNECT=y
CONFIG_INTERCONNECT_IMX=y
CONFIG_INTERCONNECT_IMX8MM=m
CONFIG_INTERCONNECT_IMX8MN=m
@@ -1544,8 +1511,8 @@ CONFIG_OVERLAY_FS=m
CONFIG_VFAT_FS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
-CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
+CONFIG_UBIFS_FS=m
CONFIG_SQUASHFS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V4=y
@@ -1593,7 +1560,6 @@ CONFIG_DEBUG_INFO_REDUCED=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
# CONFIG_SCHED_DEBUG is not set
-# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_FTRACE is not set
CONFIG_CORESIGHT=m
CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 12/13] arm64: defconfig: sync with savedefconfig
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
Sync the defconfig with savedefconfig as config options
change/move over time.
Generated with the following commands:
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
cp defconfig arch/arm64/configs/defconfig
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
1 file changed, 55 insertions(+), 89 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b60aa1f89343..09fb467303ba 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PROFILING=y
+CONFIG_KEXEC_FILE=y
+CONFIG_CRASH_DUMP=y
CONFIG_ARCH_ACTIONS=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_ALPINE=y
@@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_SMT=y
CONFIG_NUMA=y
-CONFIG_KEXEC=y
-CONFIG_KEXEC_FILE=y
-CONFIG_CRASH_DUMP=y
CONFIG_XEN=y
CONFIG_COMPAT=y
CONFIG_RANDOMIZE_BASE=y
@@ -119,7 +118,6 @@ CONFIG_KVM=y
CONFIG_JUMP_LABEL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-CONFIG_IOSCHED_BFQ=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_COMPAT_BRK is not set
CONFIG_MEMORY_HOTPLUG=y
@@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_NET=y
CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
@@ -180,8 +176,6 @@ CONFIG_NET_ACT_GATE=m
CONFIG_QRTR_SMD=m
CONFIG_QRTR_TUN=m
CONFIG_CAN=m
-CONFIG_CAN_M_CAN=m
-CONFIG_CAN_M_CAN_PLATFORM=m
CONFIG_BT=m
CONFIG_BT_HIDP=m
# CONFIG_BT_LE is not set
@@ -215,27 +209,27 @@ CONFIG_PCI_PASID=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PCI_AARDVARK=y
-CONFIG_PCI_TEGRA=y
-CONFIG_PCIE_RCAR_HOST=y
-CONFIG_PCIE_RCAR_EP=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_XGENE=y
CONFIG_PCIE_ALTERA=y
CONFIG_PCIE_ALTERA_MSI=y
+CONFIG_PCIE_BRCMSTB=m
CONFIG_PCI_HOST_THUNDER_PEM=y
CONFIG_PCI_HOST_THUNDER_ECAM=y
-CONFIG_PCIE_ROCKCHIP_HOST=m
+CONFIG_PCI_HOST_GENERIC=y
CONFIG_PCIE_MEDIATEK_GEN3=m
-CONFIG_PCIE_BRCMSTB=m
+CONFIG_PCI_TEGRA=y
+CONFIG_PCIE_RCAR_HOST=y
+CONFIG_PCIE_RCAR_EP=y
+CONFIG_PCIE_ROCKCHIP_HOST=m
+CONFIG_PCI_XGENE=y
CONFIG_PCI_IMX6_HOST=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
-CONFIG_PCIE_QCOM=y
-CONFIG_PCIE_ARMADA_8K=y
-CONFIG_PCIE_ROCKCHIP_DW_HOST=y
CONFIG_PCIE_KIRIN=y
CONFIG_PCIE_HISI_STB=y
+CONFIG_PCIE_ARMADA_8K=y
CONFIG_PCIE_TEGRA194_HOST=m
+CONFIG_PCIE_QCOM=y
+CONFIG_PCIE_ROCKCHIP_DW_HOST=y
CONFIG_PCIE_VISCONTI_HOST=y
CONFIG_PCIE_LAYERSCAPE_GEN4=y
CONFIG_PCI_ENDPOINT=y
@@ -247,14 +241,12 @@ CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_HISILICON_LPC=y
CONFIG_TEGRA_ACONNECT=m
CONFIG_MHI_BUS_PCI_GENERIC=m
-CONFIG_ARM_SCMI_PROTOCOL=y
CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_INTEL_STRATIX10_SERVICE=y
CONFIG_INTEL_STRATIX10_RSU=m
CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_IMX_SCU=y
-CONFIG_IMX_SCU_PD=y
CONFIG_GNSS=m
CONFIG_GNSS_MTK_SERIAL=m
CONFIG_MTD=y
@@ -276,15 +268,12 @@ CONFIG_MTD_NAND_FSL_IFC=y
CONFIG_MTD_NAND_QCOM=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=m
-CONFIG_UBIFS_FS=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
CONFIG_BLK_DEV_NVME=m
CONFIG_QCOM_COINCELL=m
CONFIG_QCOM_FASTRPC=m
-CONFIG_BATTERY_QCOM_BATTMGR=m
-CONFIG_UCSI_PMIC_GLINK=m
CONFIG_SRAM=y
CONFIG_PCI_ENDPOINT_TEST=m
CONFIG_EEPROM_AT24=m
@@ -308,7 +297,6 @@ CONFIG_AHCI_XGENE=y
CONFIG_AHCI_QORIQ=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_RCAR=y
-CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
@@ -384,6 +372,8 @@ CONFIG_DP83869_PHY=m
CONFIG_DP83TD510_PHY=y
CONFIG_VITESSE_PHY=y
CONFIG_CAN_FLEXCAN=m
+CONFIG_CAN_M_CAN=m
+CONFIG_CAN_M_CAN_PLATFORM=m
CONFIG_CAN_RCAR=m
CONFIG_CAN_RCAR_CANFD=m
CONFIG_CAN_MCP251XFD=m
@@ -574,9 +564,9 @@ CONFIG_PINCTRL_IMX8DXL=y
CONFIG_PINCTRL_IMX8ULP=y
CONFIG_PINCTRL_IMX93=y
CONFIG_PINCTRL_MSM=y
-CONFIG_PINCTRL_IPQ8074=y
CONFIG_PINCTRL_IPQ5018=y
CONFIG_PINCTRL_IPQ5332=y
+CONFIG_PINCTRL_IPQ8074=y
CONFIG_PINCTRL_IPQ6018=y
CONFIG_PINCTRL_IPQ9574=y
CONFIG_PINCTRL_MSM8916=y
@@ -588,34 +578,33 @@ CONFIG_PINCTRL_MSM8998=y
CONFIG_PINCTRL_QCM2290=y
CONFIG_PINCTRL_QCS404=y
CONFIG_PINCTRL_QDF2XXX=y
-CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QDU1000=y
CONFIG_PINCTRL_SA8775P=y
CONFIG_PINCTRL_SC7180=y
CONFIG_PINCTRL_SC7280=y
-CONFIG_PINCTRL_SC7280_LPASS_LPI=m
CONFIG_PINCTRL_SC8180X=y
CONFIG_PINCTRL_SC8280XP=y
CONFIG_PINCTRL_SDM660=y
CONFIG_PINCTRL_SDM670=y
CONFIG_PINCTRL_SDM845=y
CONFIG_PINCTRL_SM6115=y
-CONFIG_PINCTRL_SM6115_LPASS_LPI=m
CONFIG_PINCTRL_SM6125=y
CONFIG_PINCTRL_SM6350=y
CONFIG_PINCTRL_SM6375=y
CONFIG_PINCTRL_SM8150=y
CONFIG_PINCTRL_SM8250=y
-CONFIG_PINCTRL_SM8250_LPASS_LPI=m
CONFIG_PINCTRL_SM8350=y
-CONFIG_PINCTRL_SM8350_LPASS_LPI=m
CONFIG_PINCTRL_SM8450=y
+CONFIG_PINCTRL_SM8550=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_PINCTRL_LPASS_LPI=m
+CONFIG_PINCTRL_SC7280_LPASS_LPI=m
+CONFIG_PINCTRL_SM6115_LPASS_LPI=m
+CONFIG_PINCTRL_SM8250_LPASS_LPI=m
+CONFIG_PINCTRL_SM8350_LPASS_LPI=m
CONFIG_PINCTRL_SM8450_LPASS_LPI=m
CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
-CONFIG_PINCTRL_SM8550=y
CONFIG_PINCTRL_SM8550_LPASS_LPI=m
-CONFIG_PINCTRL_LPASS_LPI=m
-CONFIG_GPIO_AGGREGATOR=m
CONFIG_GPIO_ALTERA=m
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
@@ -624,6 +613,7 @@ CONFIG_GPIO_MPC8XXX=y
CONFIG_GPIO_MXC=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_RCAR=y
+CONFIG_GPIO_SYSCON=y
CONFIG_GPIO_UNIPHIER=y
CONFIG_GPIO_VISCONTI=y
CONFIG_GPIO_WCD934X=m
@@ -635,7 +625,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_BD9571MWV=m
CONFIG_GPIO_MAX77620=y
CONFIG_GPIO_SL28CPLD=m
-CONFIG_GPIO_SYSCON=y
+CONFIG_GPIO_AGGREGATOR=m
CONFIG_POWER_RESET_MSM=y
CONFIG_POWER_RESET_QCOM_PON=m
CONFIG_POWER_RESET_XGENE=y
@@ -643,6 +633,7 @@ CONFIG_POWER_RESET_SYSCON=y
CONFIG_POWER_RESET_SYSCON_POWEROFF=y
CONFIG_SYSCON_REBOOT_MODE=y
CONFIG_NVMEM_REBOOT_MODE=m
+CONFIG_BATTERY_QCOM_BATTMGR=m
CONFIG_BATTERY_SBS=m
CONFIG_BATTERY_BQ27XXX=y
CONFIG_BATTERY_MAX17042=m
@@ -667,8 +658,8 @@ CONFIG_DEVFREQ_THERMAL=y
CONFIG_THERMAL_EMULATION=y
CONFIG_IMX_SC_THERMAL=m
CONFIG_IMX8MM_THERMAL=m
-CONFIG_QORIQ_THERMAL=m
CONFIG_K3_THERMAL=m
+CONFIG_QORIQ_THERMAL=m
CONFIG_SUN8I_THERMAL=y
CONFIG_ROCKCHIP_THERMAL=m
CONFIG_RCAR_THERMAL=y
@@ -694,6 +685,7 @@ CONFIG_ARM_SP805_WATCHDOG=y
CONFIG_ARM_SBSA_WATCHDOG=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_DW_WATCHDOG=y
+CONFIG_K3_RTI_WATCHDOG=m
CONFIG_SUNXI_WATCHDOG=m
CONFIG_NPCM7XX_WATCHDOG=y
CONFIG_IMX2_WDT=y
@@ -709,7 +701,6 @@ CONFIG_UNIPHIER_WATCHDOG=y
CONFIG_PM8916_WATCHDOG=m
CONFIG_BCM2835_WDT=y
CONFIG_BCM7038_WDT=m
-CONFIG_K3_RTI_WATCHDOG=m
CONFIG_MFD_ALTERA_SYSMGR=y
CONFIG_MFD_BD9571MWV=y
CONFIG_MFD_AXP20X_I2C=y
@@ -726,9 +717,9 @@ CONFIG_MFD_RK8XX_SPI=y
CONFIG_MFD_SEC_CORE=y
CONFIG_MFD_SL28CPLD=y
CONFIG_RZ_MTU3=y
+CONFIG_MFD_TI_AM335X_TSCADC=m
CONFIG_MFD_TPS65219=y
CONFIG_MFD_TPS6594_I2C=m
-CONFIG_MFD_TI_AM335X_TSCADC=m
CONFIG_MFD_ROHM_BD718XX=y
CONFIG_MFD_WCD934X=m
CONFIG_MFD_KHADAS_MCU=m
@@ -832,12 +823,8 @@ CONFIG_ROCKCHIP_INNO_HDMI=y
CONFIG_ROCKCHIP_LVDS=y
CONFIG_DRM_RCAR_DU=m
CONFIG_DRM_RCAR_DW_HDMI=m
-CONFIG_DRM_RCAR_MIPI_DSI=m
CONFIG_DRM_RZG2L_MIPI_DSI=m
CONFIG_DRM_SUN4I=m
-CONFIG_DRM_SUN6I_DSI=m
-CONFIG_DRM_SUN8I_DW_HDMI=m
-CONFIG_DRM_SUN8I_MIXER=m
CONFIG_DRM_MSM=m
CONFIG_DRM_TEGRA=m
CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
@@ -856,7 +843,6 @@ CONFIG_DRM_LONTIUM_LT9611UXC=m
CONFIG_DRM_ITE_IT66121=m
CONFIG_DRM_NWL_MIPI_DSI=m
CONFIG_DRM_PARADE_PS8640=m
-CONFIG_DRM_SAMSUNG_DSIM=m
CONFIG_DRM_SII902X=m
CONFIG_DRM_SIMPLE_BRIDGE=m
CONFIG_DRM_THINE_THC63LVD1024=m
@@ -879,15 +865,15 @@ CONFIG_DRM_HISI_KIRIN=m
CONFIG_DRM_MEDIATEK=m
CONFIG_DRM_MEDIATEK_HDMI=m
CONFIG_DRM_MXSFB=m
-CONFIG_DRM_MESON=m
CONFIG_DRM_IMX_LCDIF=m
+CONFIG_DRM_MESON=m
CONFIG_DRM_PL111=m
CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
CONFIG_DRM_TIDSS=m
CONFIG_FB=y
-CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_EFI=y
+CONFIG_FB_MODE_HELPERS=y
CONFIG_BACKLIGHT_PWM=m
CONFIG_BACKLIGHT_LP855X=m
CONFIG_LOGO=y
@@ -949,7 +935,7 @@ CONFIG_SND_SOC_TEGRA210_AMX=m
CONFIG_SND_SOC_TEGRA210_ADX=m
CONFIG_SND_SOC_TEGRA210_MIXER=m
CONFIG_SND_SOC_TEGRA_AUDIO_GRAPH_CARD=m
-CONFIG_SND_SOC_DAVINCI_MCASP=m
+CONFIG_SND_SOC_J721E_EVM=m
CONFIG_SND_SOC_AK4613=m
CONFIG_SND_SOC_DA7213=m
CONFIG_SND_SOC_ES7134=m
@@ -958,10 +944,8 @@ CONFIG_SND_SOC_ES8316=m
CONFIG_SND_SOC_GTM601=m
CONFIG_SND_SOC_MSM8916_WCD_ANALOG=m
CONFIG_SND_SOC_MSM8916_WCD_DIGITAL=m
-CONFIG_SND_SOC_PCM3168A_I2C=m
CONFIG_SND_SOC_RK817=m
CONFIG_SND_SOC_RT5640=m
-CONFIG_SND_SOC_J721E_EVM=m
CONFIG_SND_SOC_RT5659=m
CONFIG_SND_SOC_SIMPLE_AMPLIFIER=m
CONFIG_SND_SOC_SIMPLE_MUX=m
@@ -980,8 +964,6 @@ CONFIG_SND_SOC_WSA881X=m
CONFIG_SND_SOC_NAU8822=m
CONFIG_SND_SOC_LPASS_WSA_MACRO=m
CONFIG_SND_SOC_LPASS_VA_MACRO=m
-CONFIG_SND_SOC_LPASS_RX_MACRO=m
-CONFIG_SND_SOC_LPASS_TX_MACRO=m
CONFIG_SND_SIMPLE_CARD=m
CONFIG_SND_AUDIO_GRAPH_CARD=m
CONFIG_SND_AUDIO_GRAPH_CARD2=m
@@ -1047,14 +1029,15 @@ CONFIG_TYPEC=m
CONFIG_TYPEC_TCPM=m
CONFIG_TYPEC_TCPCI=m
CONFIG_TYPEC_FUSB302=m
-CONFIG_TYPEC_TPS6598X=m
-CONFIG_TYPEC_HD3SS3220=m
CONFIG_TYPEC_QCOM_PMIC=m
CONFIG_TYPEC_UCSI=m
-CONFIG_TYPEC_MUX_FSA4480=m
-CONFIG_TYPEC_MUX_NB7VPQ904M=m
CONFIG_UCSI_CCG=m
+CONFIG_UCSI_PMIC_GLINK=m
+CONFIG_TYPEC_TPS6598X=m
+CONFIG_TYPEC_HD3SS3220=m
+CONFIG_TYPEC_MUX_FSA4480=m
CONFIG_TYPEC_MUX_GPIO_SBU=m
+CONFIG_TYPEC_MUX_NB7VPQ904M=m
CONFIG_TYPEC_DP_ALTMODE=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=32
@@ -1185,7 +1168,6 @@ CONFIG_CROS_EC_RPMSG=m
CONFIG_CROS_EC_SPI=y
CONFIG_CROS_EC_CHARDEV=m
CONFIG_COMMON_CLK_RK808=y
-CONFIG_COMMON_CLK_SCMI=y
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_FSL_SAI=y
@@ -1203,18 +1185,6 @@ CONFIG_CLK_IMX8QXP=y
CONFIG_CLK_IMX8ULP=y
CONFIG_CLK_IMX93=y
CONFIG_TI_SCI_CLK=y
-CONFIG_COMMON_CLK_MT8192_AUDSYS=y
-CONFIG_COMMON_CLK_MT8192_CAMSYS=y
-CONFIG_COMMON_CLK_MT8192_IMGSYS=y
-CONFIG_COMMON_CLK_MT8192_IMP_IIC_WRAP=y
-CONFIG_COMMON_CLK_MT8192_IPESYS=y
-CONFIG_COMMON_CLK_MT8192_MDPSYS=y
-CONFIG_COMMON_CLK_MT8192_MFGCFG=y
-CONFIG_COMMON_CLK_MT8192_MMSYS=y
-CONFIG_COMMON_CLK_MT8192_MSDC=y
-CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
-CONFIG_COMMON_CLK_MT8192_VDECSYS=y
-CONFIG_COMMON_CLK_MT8192_VENCSYS=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_QCOM_A53PLL=y
CONFIG_QCOM_CLK_APCS_MSM8916=y
@@ -1222,24 +1192,23 @@ CONFIG_QCOM_CLK_APCC_MSM8996=y
CONFIG_QCOM_CLK_SMD_RPM=y
CONFIG_QCOM_CLK_RPMH=y
CONFIG_IPQ_APSS_6018=y
-CONFIG_IPQ_GCC_5332=y
-CONFIG_IPQ_APSS_5018=y
CONFIG_IPQ_GCC_5018=y
+CONFIG_IPQ_GCC_5332=y
CONFIG_IPQ_GCC_6018=y
CONFIG_IPQ_GCC_8074=y
CONFIG_IPQ_GCC_9574=y
CONFIG_MSM_GCC_8916=y
+CONFIG_MSM_MMCC_8994=m
CONFIG_MSM_GCC_8994=y
CONFIG_MSM_GCC_8996=y
-CONFIG_MSM_MMCC_8994=m
CONFIG_MSM_MMCC_8996=m
-CONFIG_MSM_MMCC_8998=m
CONFIG_MSM_GCC_8998=y
+CONFIG_MSM_MMCC_8998=m
CONFIG_QCM_GCC_2290=y
CONFIG_QCM_DISPCC_2290=m
CONFIG_QCS_GCC_404=y
-CONFIG_SA_GCC_8775P=y
CONFIG_SC_DISPCC_8280XP=m
+CONFIG_SA_GCC_8775P=y
CONFIG_SA_GPUCC_8775P=m
CONFIG_SC_GCC_7180=y
CONFIG_SC_GCC_7280=y
@@ -1261,10 +1230,10 @@ CONFIG_SM_GCC_6115=y
CONFIG_SM_GCC_8350=y
CONFIG_SM_GCC_8450=y
CONFIG_SM_GCC_8550=y
-CONFIG_SM_TCSRCC_8550=y
CONFIG_SM_GPUCC_6115=m
CONFIG_SM_GPUCC_8150=y
CONFIG_SM_GPUCC_8250=y
+CONFIG_SM_TCSRCC_8550=y
CONFIG_SM_VIDEOCC_8250=y
CONFIG_QCOM_HFPLL=y
CONFIG_CLK_GFM_LPASS_SM8250=m
@@ -1275,7 +1244,6 @@ CONFIG_TEGRA186_TIMER=y
CONFIG_RENESAS_OSTM=y
CONFIG_ARM_MHU=y
CONFIG_IMX_MBOX=y
-CONFIG_OMAP2PLUS_MBOX=m
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
CONFIG_QCOM_APCS_IPC=y
@@ -1288,14 +1256,14 @@ CONFIG_MTK_IOMMU=y
CONFIG_QCOM_IOMMU=y
CONFIG_REMOTEPROC=y
CONFIG_IMX_REMOTEPROC=y
-CONFIG_TI_K3_R5_REMOTEPROC=m
-CONFIG_TI_K3_DSP_REMOTEPROC=m
CONFIG_MTK_SCP=m
CONFIG_QCOM_Q6V5_ADSP=m
CONFIG_QCOM_Q6V5_MSS=m
CONFIG_QCOM_Q6V5_PAS=m
CONFIG_QCOM_SYSMON=m
CONFIG_QCOM_WCNSS_PIL=m
+CONFIG_TI_K3_DSP_REMOTEPROC=m
+CONFIG_TI_K3_R5_REMOTEPROC=m
CONFIG_RPMSG_CHAR=m
CONFIG_RPMSG_CTRL=m
CONFIG_RPMSG_QCOM_GLINK_RPM=y
@@ -1304,8 +1272,6 @@ CONFIG_RPMSG_QCOM_SMD=y
CONFIG_RPMSG_VIRTIO=y
CONFIG_SOUNDWIRE=m
CONFIG_SOUNDWIRE_QCOM=m
-CONFIG_OWL_PM_DOMAINS=y
-CONFIG_RASPBERRYPI_POWER=y
CONFIG_FSL_DPAA=y
CONFIG_FSL_MC_DPIO=y
CONFIG_FSL_RCPM=y
@@ -1315,15 +1281,12 @@ CONFIG_MTK_PMIC_WRAP=y
CONFIG_MTK_SVS=m
CONFIG_QCOM_AOSS_QMP=y
CONFIG_QCOM_COMMAND_DB=y
-CONFIG_QCOM_CPR=y
CONFIG_QCOM_GENI_SE=y
CONFIG_QCOM_LLCC=m
CONFIG_QCOM_OCMEM=m
CONFIG_QCOM_PMIC_GLINK=m
CONFIG_QCOM_RMTFS_MEM=m
CONFIG_QCOM_RPMH=y
-CONFIG_QCOM_RPMHPD=y
-CONFIG_QCOM_RPMPD=y
CONFIG_QCOM_SMEM=y
CONFIG_QCOM_SMD_RPM=y
CONFIG_QCOM_SMP2P=y
@@ -1355,14 +1318,20 @@ CONFIG_ARCH_R9A07G054=y
CONFIG_ARCH_R9A08G045=y
CONFIG_ARCH_R9A09G011=y
CONFIG_ROCKCHIP_IODOMAIN=y
-CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_ARCH_TEGRA_132_SOC=y
CONFIG_ARCH_TEGRA_210_SOC=y
CONFIG_ARCH_TEGRA_186_SOC=y
CONFIG_ARCH_TEGRA_194_SOC=y
CONFIG_ARCH_TEGRA_234_SOC=y
-CONFIG_TI_SCI_PM_DOMAINS=y
CONFIG_TI_PRUSS=m
+CONFIG_OWL_PM_DOMAINS=y
+CONFIG_RASPBERRYPI_POWER=y
+CONFIG_IMX_SCU_PD=y
+CONFIG_QCOM_CPR=y
+CONFIG_QCOM_RPMHPD=y
+CONFIG_QCOM_RPMPD=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+CONFIG_TI_SCI_PM_DOMAINS=y
CONFIG_ARM_IMX_BUS_DEVFREQ=y
CONFIG_ARM_IMX8M_DDRC_DEVFREQ=m
CONFIG_ARM_MEDIATEK_CCI_DEVFREQ=m
@@ -1430,17 +1399,17 @@ CONFIG_PHY_HISI_INNO_USB2=y
CONFIG_PHY_MVEBU_CP110_COMPHY=y
CONFIG_PHY_MTK_TPHY=y
CONFIG_PHY_QCOM_EDP=m
-CONFIG_PHY_QCOM_EUSB2_REPEATER=m
CONFIG_PHY_QCOM_PCIE2=m
CONFIG_PHY_QCOM_QMP=m
CONFIG_PHY_QCOM_QUSB2=m
CONFIG_PHY_QCOM_SNPS_EUSB2=m
+CONFIG_PHY_QCOM_EUSB2_REPEATER=m
+CONFIG_PHY_QCOM_M31_USB=m
CONFIG_PHY_QCOM_USB_HS=m
CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=m
CONFIG_PHY_QCOM_USB_HS_28NM=m
CONFIG_PHY_QCOM_USB_SS=m
CONFIG_PHY_QCOM_SGMII_ETH=m
-CONFIG_PHY_QCOM_M31_USB=m
CONFIG_PHY_R8A779F0_ETHERNET_SERDES=y
CONFIG_PHY_RCAR_GEN3_PCIE=y
CONFIG_PHY_RCAR_GEN3_USB2=y
@@ -1462,7 +1431,6 @@ CONFIG_PHY_J721E_WIZ=m
CONFIG_ARM_CCI_PMU=m
CONFIG_ARM_CCN=m
CONFIG_ARM_CMN=m
-CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
CONFIG_ARM_SMMU_V3_PMU=m
CONFIG_ARM_DSU_PMU=m
CONFIG_FSL_IMX8_DDR_PMU=m
@@ -1471,6 +1439,7 @@ CONFIG_QCOM_L3_PMU=y
CONFIG_ARM_SPE_PMU=m
CONFIG_ARM_DMC620_PMU=m
CONFIG_HISI_PMU=y
+CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
CONFIG_MESON_DDR_PMU=m
CONFIG_NVMEM_LAYOUT_SL28_VPD=m
CONFIG_NVMEM_IMX_OCOTP=y
@@ -1498,10 +1467,8 @@ CONFIG_TEE=y
CONFIG_OPTEE=y
CONFIG_MUX_GPIO=m
CONFIG_MUX_MMIO=y
-CONFIG_SLIMBUS=m
CONFIG_SLIM_QCOM_CTRL=m
CONFIG_SLIM_QCOM_NGD_CTRL=m
-CONFIG_INTERCONNECT=y
CONFIG_INTERCONNECT_IMX=y
CONFIG_INTERCONNECT_IMX8MM=m
CONFIG_INTERCONNECT_IMX8MN=m
@@ -1544,8 +1511,8 @@ CONFIG_OVERLAY_FS=m
CONFIG_VFAT_FS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
-CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
+CONFIG_UBIFS_FS=m
CONFIG_SQUASHFS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V4=y
@@ -1593,7 +1560,6 @@ CONFIG_DEBUG_INFO_REDUCED=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
# CONFIG_SCHED_DEBUG is not set
-# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_FTRACE is not set
CONFIG_CORESIGHT=m
CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 10:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
gs101-oriole populates an at24 eeprom on the battery connector.
Make EEPROM_AT24 builtin.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 09fb467303ba..19c1d61382f6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -276,7 +276,7 @@ CONFIG_QCOM_COINCELL=m
CONFIG_QCOM_FASTRPC=m
CONFIG_SRAM=y
CONFIG_PCI_ENDPOINT_TEST=m
-CONFIG_EEPROM_AT24=m
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_AT25=m
CONFIG_UACCE=m
# CONFIG_SCSI_PROC_FS is not set
--
2.43.0.472.g3155946c3a-goog
^ permalink raw reply related [flat|nested] 122+ messages in thread
* [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin
@ 2023-12-14 10:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 10:52 UTC (permalink / raw)
To: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial, Tudor Ambarus
gs101-oriole populates an at24 eeprom on the battery connector.
Make EEPROM_AT24 builtin.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 09fb467303ba..19c1d61382f6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -276,7 +276,7 @@ CONFIG_QCOM_COINCELL=m
CONFIG_QCOM_FASTRPC=m
CONFIG_SRAM=y
CONFIG_PCI_ENDPOINT_TEST=m
-CONFIG_EEPROM_AT24=m
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_AT25=m
CONFIG_UACCE=m
# CONFIG_SCSI_PROC_FS is not set
--
2.43.0.472.g3155946c3a-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 12:01 ` Arnd Bergmann
-1 siblings, 0 replies; 122+ messages in thread
From: Arnd Bergmann @ 2023-12-14 12:01 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
> +static int __init gs101_early_console_setup(struct earlycon_device *device,
> + const char *opt)
> +{
> + /* gs101 always expects MMIO32 register accesses. */
> + device->port.iotype = UPIO_MEM32;
> +
> + return s5pv210_early_console_setup(device, opt);
> +}
> +
> +OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
It looks like this is already done by of_setup_earlycon() based on
the reg-io-width property. Any idea why it doesn't work with the
normal s5pv210_early_console_setup() function?
Arnd
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-14 12:01 ` Arnd Bergmann
0 siblings, 0 replies; 122+ messages in thread
From: Arnd Bergmann @ 2023-12-14 12:01 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
> +static int __init gs101_early_console_setup(struct earlycon_device *device,
> + const char *opt)
> +{
> + /* gs101 always expects MMIO32 register accesses. */
> + device->port.iotype = UPIO_MEM32;
> +
> + return s5pv210_early_console_setup(device, opt);
> +}
> +
> +OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
It looks like this is already done by of_setup_earlycon() based on
the reg-io-width property. Any idea why it doesn't work with the
normal s5pv210_early_console_setup() function?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 12:08 ` Arnd Bergmann
-1 siblings, 0 replies; 122+ messages in thread
From: Arnd Bergmann @ 2023-12-14 12:08 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
> Sync the defconfig with savedefconfig as config options
> change/move over time.
>
> Generated with the following commands:
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
> cp defconfig arch/arm64/configs/defconfig
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
> 1 file changed, 55 insertions(+), 89 deletions(-)
I usually ask for defconfig changes to be merged when someone just
adds a single line per patch, but a 144 line change is clearly too
big, please split this up.
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index b60aa1f89343..09fb467303ba 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_PROFILING=y
> +CONFIG_KEXEC_FILE=y
> +CONFIG_CRASH_DUMP=y
> CONFIG_ARCH_ACTIONS=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_ARCH_ALPINE=y
> @@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
> CONFIG_SCHED_MC=y
> CONFIG_SCHED_SMT=y
> CONFIG_NUMA=y
> -CONFIG_KEXEC=y
> -CONFIG_KEXEC_FILE=y
> -CONFIG_CRASH_DUMP=y
> CONFIG_XEN=y
> CONFIG_COMPAT=y
> CONFIG_RANDOMIZE_BASE=y
These two hunks seem to go together, but it needs an explanation
why you are removing CONFIG_KEXEC.
> @@ -119,7 +118,6 @@ CONFIG_KVM=y
> CONFIG_JUMP_LABEL=y
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> -CONFIG_IOSCHED_BFQ=y
> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
No, I definitely want CONFIG_IOSCHED_BFQ=y, it is essential
for performance on certain classes of machines. It would
be better to drop the 'imply IOSCHED_BFQ' in two Kconfig
files.
> @@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
> CONFIG_TRANSPARENT_HUGEPAGE=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> -CONFIG_UNIX=y
> -CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> CONFIG_IP_PNP=y
> CONFIG_IP_PNP_DHCP=y
These also seem kind of essential for almost any machine,
I assume you are doing something wrong here.
> @@ -180,8 +176,6 @@ CONFIG_NET_ACT_GATE=m
> CONFIG_QRTR_SMD=m
> CONFIG_QRTR_TUN=m
> CONFIG_CAN=m
> -CONFIG_CAN_M_CAN=m
> -CONFIG_CAN_M_CAN_PLATFORM=m
> CONFIG_BT=m
> CONFIG_BT_HIDP=m
> # CONFIG_BT_LE is not set
> @@ -384,6 +372,8 @@ CONFIG_DP83869_PHY=m
> CONFIG_DP83TD510_PHY=y
> CONFIG_VITESSE_PHY=y
> CONFIG_CAN_FLEXCAN=m
> +CONFIG_CAN_M_CAN=m
> +CONFIG_CAN_M_CAN_PLATFORM=m
> CONFIG_CAN_RCAR=m
> CONFIG_CAN_RCAR_CANFD=m
> CONFIG_CAN_MCP251XFD=m
These just get moved around in the file, please don't
mix those changes with other changes that change the behavior.
> @@ -215,27 +209,27 @@ CONFIG_PCI_PASID=y
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_ACPI=y
> CONFIG_PCI_AARDVARK=y
> -CONFIG_PCI_TEGRA=y
> -CONFIG_PCIE_RCAR_HOST=y
> -CONFIG_PCIE_RCAR_EP=y
> -CONFIG_PCI_HOST_GENERIC=y
> -CONFIG_PCI_XGENE=y
> CONFIG_PCIE_ALTERA=y
> CONFIG_PCIE_ALTERA_MSI=y
> +CONFIG_PCIE_BRCMSTB=m
> CONFIG_PCI_HOST_THUNDER_PEM=y
> CONFIG_PCI_HOST_THUNDER_ECAM=y
> -CONFIG_PCIE_ROCKCHIP_HOST=m
> +CONFIG_PCI_HOST_GENERIC=y
> CONFIG_PCIE_MEDIATEK_GEN3=m
> -CONFIG_PCIE_BRCMSTB=m
> +CONFIG_PCI_TEGRA=y
> +CONFIG_PCIE_RCAR_HOST=y
> +CONFIG_PCIE_RCAR_EP=y
> +CONFIG_PCIE_ROCKCHIP_HOST=m
> +CONFIG_PCI_XGENE=y
> CONFIG_PCI_IMX6_HOST=y
> CONFIG_PCI_LAYERSCAPE=y
> CONFIG_PCI_HISI=y
> -CONFIG_PCIE_QCOM=y
> -CONFIG_PCIE_ARMADA_8K=y
> -CONFIG_PCIE_ROCKCHIP_DW_HOST=y
> CONFIG_PCIE_KIRIN=y
> CONFIG_PCIE_HISI_STB=y
> +CONFIG_PCIE_ARMADA_8K=y
> CONFIG_PCIE_TEGRA194_HOST=m
> +CONFIG_PCIE_QCOM=y
> +CONFIG_PCIE_ROCKCHIP_DW_HOST=y
> CONFIG_PCIE_VISCONTI_HOST=y
> CONFIG_PCIE_LAYERSCAPE_GEN4=y
> CONFIG_PCI_ENDPOINT=y
Same here
> @@ -247,14 +241,12 @@ CONFIG_FW_LOADER_USER_HELPER=y
> CONFIG_HISILICON_LPC=y
> CONFIG_TEGRA_ACONNECT=m
> CONFIG_MHI_BUS_PCI_GENERIC=m
> -CONFIG_ARM_SCMI_PROTOCOL=y
> CONFIG_ARM_SCPI_PROTOCOL=y
> CONFIG_RASPBERRYPI_FIRMWARE=y
> CONFIG_INTEL_STRATIX10_SERVICE=y
> @@ -1185,7 +1168,6 @@ CONFIG_CROS_EC_RPMSG=m
> CONFIG_CROS_EC_SPI=y
> CONFIG_CROS_EC_CHARDEV=m
> CONFIG_COMMON_CLK_RK808=y
> -CONFIG_COMMON_CLK_SCMI=y
> CONFIG_COMMON_CLK_SCPI=y
> CONFIG_COMMON_CLK_CS2000_CP=y
> CONFIG_COMMON_CLK_FSL_SAI=y
This was caused by commit 9e4e24414cc6 ("arm64:
introduce STM32 family on Armv8 architecture"),
which selects ARM_SCMI_PROTOCOL and COMMON_CLK_SCMI.
I think we should instead revert those and enable
them in the defconfig for consistency with the other
platforms that need the same driver.
> CONFIG_INTEL_STRATIX10_RSU=m
> CONFIG_EFI_CAPSULE_LOADER=y
> CONFIG_IMX_SCU=y
> -CONFIG_IMX_SCU_PD=y
> CONFIG_GNSS=m
> CONFIG_GNSS_MTK_SERIAL=m
> CONFIG_MTD=y
> @@ -276,15 +268,12 @@ CONFIG_MTD_NAND_FSL_IFC=y
> CONFIG_MTD_NAND_QCOM=y
> CONFIG_MTD_SPI_NOR=y
> CONFIG_MTD_UBI=m
> -CONFIG_UBIFS_FS=m
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_NBD=m
> CONFIG_VIRTIO_BLK=y
> CONFIG_BLK_DEV_NVME=m
> CONFIG_QCOM_COINCELL=m
> CONFIG_QCOM_FASTRPC=m
> -CONFIG_BATTERY_QCOM_BATTMGR=m
> -CONFIG_UCSI_PMIC_GLINK=m
> CONFIG_SRAM=y
> CONFIG_PCI_ENDPOINT_TEST=m
> CONFIG_EEPROM_AT24=m
Again, just moved around.
> @@ -308,7 +297,6 @@ CONFIG_AHCI_XGENE=y
> CONFIG_AHCI_QORIQ=y
> CONFIG_SATA_SIL24=y
> CONFIG_SATA_RCAR=y
> -CONFIG_PATA_PLATFORM=y
> CONFIG_PATA_OF_PLATFORM=y
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=m
For the ones that got removed for a good and trivial reason,
you can probably combine the patches and just list what
happened.
> @@ -635,7 +625,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
> CONFIG_GPIO_BD9571MWV=m
> CONFIG_GPIO_MAX77620=y
> CONFIG_GPIO_SL28CPLD=m
> -CONFIG_GPIO_SYSCON=y
Apparently caused by GPIO_SAMA5D2_PIOBU, please change that
to 'depends on'.
> @@ -856,7 +843,6 @@ CONFIG_DRM_LONTIUM_LT9611UXC=m
> CONFIG_DRM_ITE_IT66121=m
> CONFIG_DRM_NWL_MIPI_DSI=m
> CONFIG_DRM_PARADE_PS8640=m
> -CONFIG_DRM_SAMSUNG_DSIM=m
> CONFIG_DRM_SII902X=m
> CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_THINE_THC63LVD1024=m
DRM_EXYNOS_DSI should probably depend on this rather than
selecting it.
> @@ -1203,18 +1185,6 @@ CONFIG_CLK_IMX8QXP=y
> CONFIG_CLK_IMX8ULP=y
> CONFIG_CLK_IMX93=y
> CONFIG_TI_SCI_CLK=y
> -CONFIG_COMMON_CLK_MT8192_AUDSYS=y
> -CONFIG_COMMON_CLK_MT8192_CAMSYS=y
> -CONFIG_COMMON_CLK_MT8192_IMGSYS=y
> -CONFIG_COMMON_CLK_MT8192_IMP_IIC_WRAP=y
> -CONFIG_COMMON_CLK_MT8192_IPESYS=y
> -CONFIG_COMMON_CLK_MT8192_MDPSYS=y
> -CONFIG_COMMON_CLK_MT8192_MFGCFG=y
> -CONFIG_COMMON_CLK_MT8192_MMSYS=y
> -CONFIG_COMMON_CLK_MT8192_MSDC=y
> -CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
> -CONFIG_COMMON_CLK_MT8192_VDECSYS=y
> -CONFIG_COMMON_CLK_MT8192_VENCSYS=y
> CONFIG_COMMON_CLK_QCOM=y
> CONFIG_QCOM_A53PLL=y
> CONFIG_QCOM_CLK_APCS_MSM8916=y
These looks legitimate
> @@ -1275,7 +1244,6 @@ CONFIG_TEGRA186_TIMER=y
> CONFIG_RENESAS_OSTM=y
> CONFIG_ARM_MHU=y
> CONFIG_IMX_MBOX=y
> -CONFIG_OMAP2PLUS_MBOX=m
> CONFIG_PLATFORM_MHU=y
> CONFIG_BCM2835_MBOX=y
> CONFIG_QCOM_APCS_IPC=y
Again we have a mix of select and depends:
drivers/remoteproc/Kconfig: select OMAP2PLUS_MBOX
drivers/remoteproc/Kconfig: select OMAP2PLUS_MBOX
drivers/remoteproc/Kconfig: select OMAP2PLUS_MBOX
drivers/soc/ti/Kconfig: depends on OMAP2PLUS_MBOX
We probably want the latter for all of them.
> @@ -1462,7 +1431,6 @@ CONFIG_PHY_J721E_WIZ=m
> CONFIG_ARM_CCI_PMU=m
> CONFIG_ARM_CCN=m
> CONFIG_ARM_CMN=m
> -CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
> CONFIG_ARM_SMMU_V3_PMU=m
> CONFIG_ARM_DSU_PMU=m
> CONFIG_FSL_IMX8_DDR_PMU=m
> @@ -1471,6 +1439,7 @@ CONFIG_QCOM_L3_PMU=y
> CONFIG_ARM_SPE_PMU=m
> CONFIG_ARM_DMC620_PMU=m
> CONFIG_HISI_PMU=y
> +CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
> CONFIG_MESON_DDR_PMU=m
> CONFIG_NVMEM_LAYOUT_SL28_VPD=m
> CONFIG_NVMEM_IMX_OCOTP=y
Just moved
> @@ -1498,10 +1467,8 @@ CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_MUX_GPIO=m
> CONFIG_MUX_MMIO=y
> -CONFIG_SLIMBUS=m
> CONFIG_SLIM_QCOM_CTRL=m
Please fix SOUNDWIRE_QCOM to no longer 'imply SLIMBUS'.
> CONFIG_SLIM_QCOM_NGD_CTRL=m
> -CONFIG_INTERCONNECT=y
> CONFIG_INTERCONNECT_IMX=y
> CONFIG_INTERCONNECT_IMX8MM=m
> CONFIG_INTERCONNECT_IMX8MN=m
I think the problem here are some Tegra device drivers that
incorrectly 'select INTERCONNECT' rather than using the
'depends on' that every other interconnect driver has.
Please fix those instead.
> @@ -1544,8 +1511,8 @@ CONFIG_OVERLAY_FS=m
> CONFIG_VFAT_FS=y
> CONFIG_TMPFS_POSIX_ACL=y
> CONFIG_HUGETLBFS=y
> -CONFIG_CONFIGFS_FS=y
> CONFIG_EFIVAR_FS=y
For CONFIG_CONFIGFS_FS, we have a mix of 'depends on' and 'select'
in the Kconfig options that use it. Before you remove this here,
let's discuss with all the users which of the two should actually
be used and then change them to be consistent.
> @@ -1593,7 +1560,6 @@ CONFIG_DEBUG_INFO_REDUCED=y
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_DEBUG_FS=y
> # CONFIG_SCHED_DEBUG is not set
> -# CONFIG_DEBUG_PREEMPT is not set
> # CONFIG_FTRACE is not set
> CONFIG_CORESIGHT=m
> CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m
These looks sensible. Can you do the same thing for
arch/arm/configs/* in a combined patch?
Arnd
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
@ 2023-12-14 12:08 ` Arnd Bergmann
0 siblings, 0 replies; 122+ messages in thread
From: Arnd Bergmann @ 2023-12-14 12:08 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
> Sync the defconfig with savedefconfig as config options
> change/move over time.
>
> Generated with the following commands:
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
> cp defconfig arch/arm64/configs/defconfig
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
> 1 file changed, 55 insertions(+), 89 deletions(-)
I usually ask for defconfig changes to be merged when someone just
adds a single line per patch, but a 144 line change is clearly too
big, please split this up.
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index b60aa1f89343..09fb467303ba 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_PROFILING=y
> +CONFIG_KEXEC_FILE=y
> +CONFIG_CRASH_DUMP=y
> CONFIG_ARCH_ACTIONS=y
> CONFIG_ARCH_SUNXI=y
> CONFIG_ARCH_ALPINE=y
> @@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
> CONFIG_SCHED_MC=y
> CONFIG_SCHED_SMT=y
> CONFIG_NUMA=y
> -CONFIG_KEXEC=y
> -CONFIG_KEXEC_FILE=y
> -CONFIG_CRASH_DUMP=y
> CONFIG_XEN=y
> CONFIG_COMPAT=y
> CONFIG_RANDOMIZE_BASE=y
These two hunks seem to go together, but it needs an explanation
why you are removing CONFIG_KEXEC.
> @@ -119,7 +118,6 @@ CONFIG_KVM=y
> CONFIG_JUMP_LABEL=y
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> -CONFIG_IOSCHED_BFQ=y
> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> # CONFIG_COMPAT_BRK is not set
> CONFIG_MEMORY_HOTPLUG=y
No, I definitely want CONFIG_IOSCHED_BFQ=y, it is essential
for performance on certain classes of machines. It would
be better to drop the 'imply IOSCHED_BFQ' in two Kconfig
files.
> @@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
> CONFIG_TRANSPARENT_HUGEPAGE=y
> CONFIG_NET=y
> CONFIG_PACKET=y
> -CONFIG_UNIX=y
> -CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> CONFIG_IP_PNP=y
> CONFIG_IP_PNP_DHCP=y
These also seem kind of essential for almost any machine,
I assume you are doing something wrong here.
> @@ -180,8 +176,6 @@ CONFIG_NET_ACT_GATE=m
> CONFIG_QRTR_SMD=m
> CONFIG_QRTR_TUN=m
> CONFIG_CAN=m
> -CONFIG_CAN_M_CAN=m
> -CONFIG_CAN_M_CAN_PLATFORM=m
> CONFIG_BT=m
> CONFIG_BT_HIDP=m
> # CONFIG_BT_LE is not set
> @@ -384,6 +372,8 @@ CONFIG_DP83869_PHY=m
> CONFIG_DP83TD510_PHY=y
> CONFIG_VITESSE_PHY=y
> CONFIG_CAN_FLEXCAN=m
> +CONFIG_CAN_M_CAN=m
> +CONFIG_CAN_M_CAN_PLATFORM=m
> CONFIG_CAN_RCAR=m
> CONFIG_CAN_RCAR_CANFD=m
> CONFIG_CAN_MCP251XFD=m
These just get moved around in the file, please don't
mix those changes with other changes that change the behavior.
> @@ -215,27 +209,27 @@ CONFIG_PCI_PASID=y
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_ACPI=y
> CONFIG_PCI_AARDVARK=y
> -CONFIG_PCI_TEGRA=y
> -CONFIG_PCIE_RCAR_HOST=y
> -CONFIG_PCIE_RCAR_EP=y
> -CONFIG_PCI_HOST_GENERIC=y
> -CONFIG_PCI_XGENE=y
> CONFIG_PCIE_ALTERA=y
> CONFIG_PCIE_ALTERA_MSI=y
> +CONFIG_PCIE_BRCMSTB=m
> CONFIG_PCI_HOST_THUNDER_PEM=y
> CONFIG_PCI_HOST_THUNDER_ECAM=y
> -CONFIG_PCIE_ROCKCHIP_HOST=m
> +CONFIG_PCI_HOST_GENERIC=y
> CONFIG_PCIE_MEDIATEK_GEN3=m
> -CONFIG_PCIE_BRCMSTB=m
> +CONFIG_PCI_TEGRA=y
> +CONFIG_PCIE_RCAR_HOST=y
> +CONFIG_PCIE_RCAR_EP=y
> +CONFIG_PCIE_ROCKCHIP_HOST=m
> +CONFIG_PCI_XGENE=y
> CONFIG_PCI_IMX6_HOST=y
> CONFIG_PCI_LAYERSCAPE=y
> CONFIG_PCI_HISI=y
> -CONFIG_PCIE_QCOM=y
> -CONFIG_PCIE_ARMADA_8K=y
> -CONFIG_PCIE_ROCKCHIP_DW_HOST=y
> CONFIG_PCIE_KIRIN=y
> CONFIG_PCIE_HISI_STB=y
> +CONFIG_PCIE_ARMADA_8K=y
> CONFIG_PCIE_TEGRA194_HOST=m
> +CONFIG_PCIE_QCOM=y
> +CONFIG_PCIE_ROCKCHIP_DW_HOST=y
> CONFIG_PCIE_VISCONTI_HOST=y
> CONFIG_PCIE_LAYERSCAPE_GEN4=y
> CONFIG_PCI_ENDPOINT=y
Same here
> @@ -247,14 +241,12 @@ CONFIG_FW_LOADER_USER_HELPER=y
> CONFIG_HISILICON_LPC=y
> CONFIG_TEGRA_ACONNECT=m
> CONFIG_MHI_BUS_PCI_GENERIC=m
> -CONFIG_ARM_SCMI_PROTOCOL=y
> CONFIG_ARM_SCPI_PROTOCOL=y
> CONFIG_RASPBERRYPI_FIRMWARE=y
> CONFIG_INTEL_STRATIX10_SERVICE=y
> @@ -1185,7 +1168,6 @@ CONFIG_CROS_EC_RPMSG=m
> CONFIG_CROS_EC_SPI=y
> CONFIG_CROS_EC_CHARDEV=m
> CONFIG_COMMON_CLK_RK808=y
> -CONFIG_COMMON_CLK_SCMI=y
> CONFIG_COMMON_CLK_SCPI=y
> CONFIG_COMMON_CLK_CS2000_CP=y
> CONFIG_COMMON_CLK_FSL_SAI=y
This was caused by commit 9e4e24414cc6 ("arm64:
introduce STM32 family on Armv8 architecture"),
which selects ARM_SCMI_PROTOCOL and COMMON_CLK_SCMI.
I think we should instead revert those and enable
them in the defconfig for consistency with the other
platforms that need the same driver.
> CONFIG_INTEL_STRATIX10_RSU=m
> CONFIG_EFI_CAPSULE_LOADER=y
> CONFIG_IMX_SCU=y
> -CONFIG_IMX_SCU_PD=y
> CONFIG_GNSS=m
> CONFIG_GNSS_MTK_SERIAL=m
> CONFIG_MTD=y
> @@ -276,15 +268,12 @@ CONFIG_MTD_NAND_FSL_IFC=y
> CONFIG_MTD_NAND_QCOM=y
> CONFIG_MTD_SPI_NOR=y
> CONFIG_MTD_UBI=m
> -CONFIG_UBIFS_FS=m
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_NBD=m
> CONFIG_VIRTIO_BLK=y
> CONFIG_BLK_DEV_NVME=m
> CONFIG_QCOM_COINCELL=m
> CONFIG_QCOM_FASTRPC=m
> -CONFIG_BATTERY_QCOM_BATTMGR=m
> -CONFIG_UCSI_PMIC_GLINK=m
> CONFIG_SRAM=y
> CONFIG_PCI_ENDPOINT_TEST=m
> CONFIG_EEPROM_AT24=m
Again, just moved around.
> @@ -308,7 +297,6 @@ CONFIG_AHCI_XGENE=y
> CONFIG_AHCI_QORIQ=y
> CONFIG_SATA_SIL24=y
> CONFIG_SATA_RCAR=y
> -CONFIG_PATA_PLATFORM=y
> CONFIG_PATA_OF_PLATFORM=y
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=m
For the ones that got removed for a good and trivial reason,
you can probably combine the patches and just list what
happened.
> @@ -635,7 +625,7 @@ CONFIG_GPIO_PCA953X_IRQ=y
> CONFIG_GPIO_BD9571MWV=m
> CONFIG_GPIO_MAX77620=y
> CONFIG_GPIO_SL28CPLD=m
> -CONFIG_GPIO_SYSCON=y
Apparently caused by GPIO_SAMA5D2_PIOBU, please change that
to 'depends on'.
> @@ -856,7 +843,6 @@ CONFIG_DRM_LONTIUM_LT9611UXC=m
> CONFIG_DRM_ITE_IT66121=m
> CONFIG_DRM_NWL_MIPI_DSI=m
> CONFIG_DRM_PARADE_PS8640=m
> -CONFIG_DRM_SAMSUNG_DSIM=m
> CONFIG_DRM_SII902X=m
> CONFIG_DRM_SIMPLE_BRIDGE=m
> CONFIG_DRM_THINE_THC63LVD1024=m
DRM_EXYNOS_DSI should probably depend on this rather than
selecting it.
> @@ -1203,18 +1185,6 @@ CONFIG_CLK_IMX8QXP=y
> CONFIG_CLK_IMX8ULP=y
> CONFIG_CLK_IMX93=y
> CONFIG_TI_SCI_CLK=y
> -CONFIG_COMMON_CLK_MT8192_AUDSYS=y
> -CONFIG_COMMON_CLK_MT8192_CAMSYS=y
> -CONFIG_COMMON_CLK_MT8192_IMGSYS=y
> -CONFIG_COMMON_CLK_MT8192_IMP_IIC_WRAP=y
> -CONFIG_COMMON_CLK_MT8192_IPESYS=y
> -CONFIG_COMMON_CLK_MT8192_MDPSYS=y
> -CONFIG_COMMON_CLK_MT8192_MFGCFG=y
> -CONFIG_COMMON_CLK_MT8192_MMSYS=y
> -CONFIG_COMMON_CLK_MT8192_MSDC=y
> -CONFIG_COMMON_CLK_MT8192_SCP_ADSP=y
> -CONFIG_COMMON_CLK_MT8192_VDECSYS=y
> -CONFIG_COMMON_CLK_MT8192_VENCSYS=y
> CONFIG_COMMON_CLK_QCOM=y
> CONFIG_QCOM_A53PLL=y
> CONFIG_QCOM_CLK_APCS_MSM8916=y
These looks legitimate
> @@ -1275,7 +1244,6 @@ CONFIG_TEGRA186_TIMER=y
> CONFIG_RENESAS_OSTM=y
> CONFIG_ARM_MHU=y
> CONFIG_IMX_MBOX=y
> -CONFIG_OMAP2PLUS_MBOX=m
> CONFIG_PLATFORM_MHU=y
> CONFIG_BCM2835_MBOX=y
> CONFIG_QCOM_APCS_IPC=y
Again we have a mix of select and depends:
drivers/remoteproc/Kconfig: select OMAP2PLUS_MBOX
drivers/remoteproc/Kconfig: select OMAP2PLUS_MBOX
drivers/remoteproc/Kconfig: select OMAP2PLUS_MBOX
drivers/soc/ti/Kconfig: depends on OMAP2PLUS_MBOX
We probably want the latter for all of them.
> @@ -1462,7 +1431,6 @@ CONFIG_PHY_J721E_WIZ=m
> CONFIG_ARM_CCI_PMU=m
> CONFIG_ARM_CCN=m
> CONFIG_ARM_CMN=m
> -CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
> CONFIG_ARM_SMMU_V3_PMU=m
> CONFIG_ARM_DSU_PMU=m
> CONFIG_FSL_IMX8_DDR_PMU=m
> @@ -1471,6 +1439,7 @@ CONFIG_QCOM_L3_PMU=y
> CONFIG_ARM_SPE_PMU=m
> CONFIG_ARM_DMC620_PMU=m
> CONFIG_HISI_PMU=y
> +CONFIG_ARM_CORESIGHT_PMU_ARCH_SYSTEM_PMU=m
> CONFIG_MESON_DDR_PMU=m
> CONFIG_NVMEM_LAYOUT_SL28_VPD=m
> CONFIG_NVMEM_IMX_OCOTP=y
Just moved
> @@ -1498,10 +1467,8 @@ CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_MUX_GPIO=m
> CONFIG_MUX_MMIO=y
> -CONFIG_SLIMBUS=m
> CONFIG_SLIM_QCOM_CTRL=m
Please fix SOUNDWIRE_QCOM to no longer 'imply SLIMBUS'.
> CONFIG_SLIM_QCOM_NGD_CTRL=m
> -CONFIG_INTERCONNECT=y
> CONFIG_INTERCONNECT_IMX=y
> CONFIG_INTERCONNECT_IMX8MM=m
> CONFIG_INTERCONNECT_IMX8MN=m
I think the problem here are some Tegra device drivers that
incorrectly 'select INTERCONNECT' rather than using the
'depends on' that every other interconnect driver has.
Please fix those instead.
> @@ -1544,8 +1511,8 @@ CONFIG_OVERLAY_FS=m
> CONFIG_VFAT_FS=y
> CONFIG_TMPFS_POSIX_ACL=y
> CONFIG_HUGETLBFS=y
> -CONFIG_CONFIGFS_FS=y
> CONFIG_EFIVAR_FS=y
For CONFIG_CONFIGFS_FS, we have a mix of 'depends on' and 'select'
in the Kconfig options that use it. Before you remove this here,
let's discuss with all the users which of the two should actually
be used and then change them to be consistent.
> @@ -1593,7 +1560,6 @@ CONFIG_DEBUG_INFO_REDUCED=y
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_DEBUG_FS=y
> # CONFIG_SCHED_DEBUG is not set
> -# CONFIG_DEBUG_PREEMPT is not set
> # CONFIG_FTRACE is not set
> CONFIG_CORESIGHT=m
> CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m
These looks sensible. Can you do the same thing for
arch/arm/configs/* in a combined patch?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 13:06 ` Wolfram Sang
-1 siblings, 0 replies; 122+ messages in thread
From: Wolfram Sang @ 2023-12-14 13:06 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
On Thu, Dec 14, 2023 at 10:52:33AM +0000, Tudor Ambarus wrote:
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
@ 2023-12-14 13:06 ` Wolfram Sang
0 siblings, 0 replies; 122+ messages in thread
From: Wolfram Sang @ 2023-12-14 13:06 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
[-- Attachment #1.1: Type: text/plain, Size: 264 bytes --]
On Thu, Dec 14, 2023 at 10:52:33AM +0000, Tudor Ambarus wrote:
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
2023-12-14 12:08 ` Arnd Bergmann
@ 2023-12-14 13:19 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-14 13:19 UTC (permalink / raw)
To: Arnd Bergmann, Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 14/12/2023 13:08, Arnd Bergmann wrote:
> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>> Sync the defconfig with savedefconfig as config options
>> change/move over time.
>>
>> Generated with the following commands:
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
>> cp defconfig arch/arm64/configs/defconfig
These are obvious. You cannot do it differently.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>> 1 file changed, 55 insertions(+), 89 deletions(-)
>
> I usually ask for defconfig changes to be merged when someone just
> adds a single line per patch, but a 144 line change is clearly too
> big, please split this up.
Anyway this should not go via my tree, because of possible conflicts.
This commit, so the savedefconfig, must be prepared on linux-next, which
should be mentioned in changelog for example. It also is not related to
this patchset.
>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index b60aa1f89343..09fb467303ba 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
>> CONFIG_BLK_DEV_INITRD=y
>> CONFIG_KALLSYMS_ALL=y
>> CONFIG_PROFILING=y
>> +CONFIG_KEXEC_FILE=y
>> +CONFIG_CRASH_DUMP=y
>> CONFIG_ARCH_ACTIONS=y
>> CONFIG_ARCH_SUNXI=y
>> CONFIG_ARCH_ALPINE=y
>> @@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
>> CONFIG_SCHED_MC=y
>> CONFIG_SCHED_SMT=y
>> CONFIG_NUMA=y
>> -CONFIG_KEXEC=y
>> -CONFIG_KEXEC_FILE=y
>> -CONFIG_CRASH_DUMP=y
>> CONFIG_XEN=y
>> CONFIG_COMPAT=y
>> CONFIG_RANDOMIZE_BASE=y
>
> These two hunks seem to go together, but it needs an explanation
> why you are removing CONFIG_KEXEC.
>
>> @@ -119,7 +118,6 @@ CONFIG_KVM=y
>> CONFIG_JUMP_LABEL=y
>> CONFIG_MODULES=y
>> CONFIG_MODULE_UNLOAD=y
>> -CONFIG_IOSCHED_BFQ=y
>> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>> # CONFIG_COMPAT_BRK is not set
>> CONFIG_MEMORY_HOTPLUG=y
>
> No, I definitely want CONFIG_IOSCHED_BFQ=y, it is essential
> for performance on certain classes of machines. It would
> be better to drop the 'imply IOSCHED_BFQ' in two Kconfig
> files.
>
>> @@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
>> CONFIG_TRANSPARENT_HUGEPAGE=y
>> CONFIG_NET=y
>> CONFIG_PACKET=y
>> -CONFIG_UNIX=y
>> -CONFIG_INET=y
>> CONFIG_IP_MULTICAST=y
>> CONFIG_IP_PNP=y
>> CONFIG_IP_PNP_DHCP=y
>
> These also seem kind of essential for almost any machine,
> I assume you are doing something wrong here.
Yep. I think the folks forget the rule not to remove user-selectable
options :/
>
...
>
>> CONFIG_SLIM_QCOM_NGD_CTRL=m
>> -CONFIG_INTERCONNECT=y
>> CONFIG_INTERCONNECT_IMX=y
>> CONFIG_INTERCONNECT_IMX8MM=m
>> CONFIG_INTERCONNECT_IMX8MN=m
>
> I think the problem here are some Tegra device drivers that
> incorrectly 'select INTERCONNECT' rather than using the
> 'depends on' that every other interconnect driver has.
> Please fix those instead.
In current setup interconnect is user-selectable, so it must not be removed.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
@ 2023-12-14 13:19 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-14 13:19 UTC (permalink / raw)
To: Arnd Bergmann, Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 14/12/2023 13:08, Arnd Bergmann wrote:
> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>> Sync the defconfig with savedefconfig as config options
>> change/move over time.
>>
>> Generated with the following commands:
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
>> cp defconfig arch/arm64/configs/defconfig
These are obvious. You cannot do it differently.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>> 1 file changed, 55 insertions(+), 89 deletions(-)
>
> I usually ask for defconfig changes to be merged when someone just
> adds a single line per patch, but a 144 line change is clearly too
> big, please split this up.
Anyway this should not go via my tree, because of possible conflicts.
This commit, so the savedefconfig, must be prepared on linux-next, which
should be mentioned in changelog for example. It also is not related to
this patchset.
>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index b60aa1f89343..09fb467303ba 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -30,6 +30,8 @@ CONFIG_SCHED_AUTOGROUP=y
>> CONFIG_BLK_DEV_INITRD=y
>> CONFIG_KALLSYMS_ALL=y
>> CONFIG_PROFILING=y
>> +CONFIG_KEXEC_FILE=y
>> +CONFIG_CRASH_DUMP=y
>> CONFIG_ARCH_ACTIONS=y
>> CONFIG_ARCH_SUNXI=y
>> CONFIG_ARCH_ALPINE=y
>> @@ -77,9 +79,6 @@ CONFIG_ARM64_VA_BITS_48=y
>> CONFIG_SCHED_MC=y
>> CONFIG_SCHED_SMT=y
>> CONFIG_NUMA=y
>> -CONFIG_KEXEC=y
>> -CONFIG_KEXEC_FILE=y
>> -CONFIG_CRASH_DUMP=y
>> CONFIG_XEN=y
>> CONFIG_COMPAT=y
>> CONFIG_RANDOMIZE_BASE=y
>
> These two hunks seem to go together, but it needs an explanation
> why you are removing CONFIG_KEXEC.
>
>> @@ -119,7 +118,6 @@ CONFIG_KVM=y
>> CONFIG_JUMP_LABEL=y
>> CONFIG_MODULES=y
>> CONFIG_MODULE_UNLOAD=y
>> -CONFIG_IOSCHED_BFQ=y
>> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>> # CONFIG_COMPAT_BRK is not set
>> CONFIG_MEMORY_HOTPLUG=y
>
> No, I definitely want CONFIG_IOSCHED_BFQ=y, it is essential
> for performance on certain classes of machines. It would
> be better to drop the 'imply IOSCHED_BFQ' in two Kconfig
> files.
>
>> @@ -129,8 +127,6 @@ CONFIG_MEMORY_FAILURE=y
>> CONFIG_TRANSPARENT_HUGEPAGE=y
>> CONFIG_NET=y
>> CONFIG_PACKET=y
>> -CONFIG_UNIX=y
>> -CONFIG_INET=y
>> CONFIG_IP_MULTICAST=y
>> CONFIG_IP_PNP=y
>> CONFIG_IP_PNP_DHCP=y
>
> These also seem kind of essential for almost any machine,
> I assume you are doing something wrong here.
Yep. I think the folks forget the rule not to remove user-selectable
options :/
>
...
>
>> CONFIG_SLIM_QCOM_NGD_CTRL=m
>> -CONFIG_INTERCONNECT=y
>> CONFIG_INTERCONNECT_IMX=y
>> CONFIG_INTERCONNECT_IMX8MM=m
>> CONFIG_INTERCONNECT_IMX8MN=m
>
> I think the problem here are some Tegra device drivers that
> incorrectly 'select INTERCONNECT' rather than using the
> 'depends on' that every other interconnect driver has.
> Please fix those instead.
In current setup interconnect is user-selectable, so it must not be removed.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 13:20 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-14 13:20 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> gs101-oriole populates an at24 eeprom on the battery connector.
> Make EEPROM_AT24 builtin.
The first sentence does not explain me the second part. The first
sentence justifies having this enabled in general, but not necessarily
as built-in.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin
@ 2023-12-14 13:20 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-14 13:20 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> gs101-oriole populates an at24 eeprom on the battery connector.
> Make EEPROM_AT24 builtin.
The first sentence does not explain me the second part. The first
sentence justifies having this enabled in general, but not necessarily
as built-in.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-14 12:01 ` Arnd Bergmann
@ 2023-12-14 13:52 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 13:52 UTC (permalink / raw)
To: Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/14/23 12:01, Arnd Bergmann wrote:
Hi, Arnd,
Thanks for the review!
> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>> + const char *opt)
>> +{
>> + /* gs101 always expects MMIO32 register accesses. */
>> + device->port.iotype = UPIO_MEM32;
>> +
>> + return s5pv210_early_console_setup(device, opt);
>> +}
>> +
>> +OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
>
> It looks like this is already done by of_setup_earlycon() based on
> the reg-io-width property. Any idea why it doesn't work with the
> normal s5pv210_early_console_setup() function?
>
It works if in device tree one specifies the reg-io-width property and
sets it to 4. If the reg-io-width is not specified, the iotype defaults
to UPIO_MEM causing the SError interrupt on gs101 which makes the system
unusable.
Also, if the earlycon comes specified from the kernel params, the
of_setup_earlycon() is no longer called and the earlycon will be set
solely based on the kernel params buffer, thus allowing users to crash
the kernel on wrong earlycon definitions.
If you think the change is fine, I can amend the commit message with the
description from above.
Cheers,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-14 13:52 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 13:52 UTC (permalink / raw)
To: Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/14/23 12:01, Arnd Bergmann wrote:
Hi, Arnd,
Thanks for the review!
> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>> + const char *opt)
>> +{
>> + /* gs101 always expects MMIO32 register accesses. */
>> + device->port.iotype = UPIO_MEM32;
>> +
>> + return s5pv210_early_console_setup(device, opt);
>> +}
>> +
>> +OF_EARLYCON_DECLARE(gs101, "google,gs101-uart", gs101_early_console_setup);
>
> It looks like this is already done by of_setup_earlycon() based on
> the reg-io-width property. Any idea why it doesn't work with the
> normal s5pv210_early_console_setup() function?
>
It works if in device tree one specifies the reg-io-width property and
sets it to 4. If the reg-io-width is not specified, the iotype defaults
to UPIO_MEM causing the SError interrupt on gs101 which makes the system
unusable.
Also, if the earlycon comes specified from the kernel params, the
of_setup_earlycon() is no longer called and the earlycon will be set
solely based on the kernel params buffer, thus allowing users to crash
the kernel on wrong earlycon definitions.
If you think the change is fine, I can amend the commit message with the
description from above.
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
2023-12-14 13:19 ` Krzysztof Kozlowski
@ 2023-12-14 14:09 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 14:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/14/23 13:19, Krzysztof Kozlowski wrote:
> On 14/12/2023 13:08, Arnd Bergmann wrote:
Hi, Arnd, Krzysztof,
Thanks for the review!
>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>> Sync the defconfig with savedefconfig as config options
>>> change/move over time.
>>>
>>> Generated with the following commands:
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
>>> cp defconfig arch/arm64/configs/defconfig
> These are obvious. You cannot do it differently.
This was just a prerequisite patch for the next, where I made a config
builtin. Modifying defconfig shall be made in a similar manner, but it
seems it's not the case (144 line change here), and that's why I
considered it is worth specifying how I did it.
>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> ---
>>> arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>>> 1 file changed, 55 insertions(+), 89 deletions(-)
>> I usually ask for defconfig changes to be merged when someone just
>> adds a single line per patch, but a 144 line change is clearly too
>> big, please split this up.
The truth is I didn't think we care what configs get removed after a
savedefconfig. I see now after Arnd's review that we have a higher goal
and savedefconfig shall be used to identify misconfiguration.
> Anyway this should not go via my tree, because of possible conflicts.
> This commit, so the savedefconfig, must be prepared on linux-next, which
> should be mentioned in changelog for example. It also is not related to
> this patchset.
Please ignore this patch. Cheers,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 12/13] arm64: defconfig: sync with savedefconfig
@ 2023-12-14 14:09 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 14:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/14/23 13:19, Krzysztof Kozlowski wrote:
> On 14/12/2023 13:08, Arnd Bergmann wrote:
Hi, Arnd, Krzysztof,
Thanks for the review!
>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>> Sync the defconfig with savedefconfig as config options
>>> change/move over time.
>>>
>>> Generated with the following commands:
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- savedefconfig
>>> cp defconfig arch/arm64/configs/defconfig
> These are obvious. You cannot do it differently.
This was just a prerequisite patch for the next, where I made a config
builtin. Modifying defconfig shall be made in a similar manner, but it
seems it's not the case (144 line change here), and that's why I
considered it is worth specifying how I did it.
>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> ---
>>> arch/arm64/configs/defconfig | 144 +++++++++++++----------------------
>>> 1 file changed, 55 insertions(+), 89 deletions(-)
>> I usually ask for defconfig changes to be merged when someone just
>> adds a single line per patch, but a 144 line change is clearly too
>> big, please split this up.
The truth is I didn't think we care what configs get removed after a
savedefconfig. I see now after Arnd's review that we have a higher goal
and savedefconfig shall be used to identify misconfiguration.
> Anyway this should not go via my tree, because of possible conflicts.
> This commit, so the savedefconfig, must be prepared on linux-next, which
> should be mentioned in changelog for example. It also is not related to
> this patchset.
Please ignore this patch. Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-14 13:52 ` Tudor Ambarus
@ 2023-12-14 14:19 ` Arnd Bergmann
-1 siblings, 0 replies; 122+ messages in thread
From: Arnd Bergmann @ 2023-12-14 14:19 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
> On 12/14/23 12:01, Arnd Bergmann wrote:
>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>
>
> It works if in device tree one specifies the reg-io-width property and
> sets it to 4. If the reg-io-width is not specified, the iotype defaults
> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
> unusable.
In the case of incorrect DT data like a missing reg-io-width property,
I would expect it to still fail once the regular console or tty takes
over from earlycon.
> Also, if the earlycon comes specified from the kernel params, the
> of_setup_earlycon() is no longer called and the earlycon will be set
> solely based on the kernel params buffer, thus allowing users to crash
> the kernel on wrong earlycon definitions.
But that in turn is the same as specifying any other incorrect earlycon.
> If you think the change is fine, I can amend the commit message with the
> description from above.
I'm still not convinced we need a special case here when everything else
just requires passing the correct data.
Arnd
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-14 14:19 ` Arnd Bergmann
0 siblings, 0 replies; 122+ messages in thread
From: Arnd Bergmann @ 2023-12-14 14:19 UTC (permalink / raw)
To: Tudor Ambarus, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
> On 12/14/23 12:01, Arnd Bergmann wrote:
>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>
>
> It works if in device tree one specifies the reg-io-width property and
> sets it to 4. If the reg-io-width is not specified, the iotype defaults
> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
> unusable.
In the case of incorrect DT data like a missing reg-io-width property,
I would expect it to still fail once the regular console or tty takes
over from earlycon.
> Also, if the earlycon comes specified from the kernel params, the
> of_setup_earlycon() is no longer called and the earlycon will be set
> solely based on the kernel params buffer, thus allowing users to crash
> the kernel on wrong earlycon definitions.
But that in turn is the same as specifying any other incorrect earlycon.
> If you think the change is fine, I can amend the commit message with the
> description from above.
I'm still not convinced we need a special case here when everything else
just requires passing the correct data.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-14 14:19 ` Arnd Bergmann
@ 2023-12-14 14:31 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 14:31 UTC (permalink / raw)
To: Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/14/23 14:19, Arnd Bergmann wrote:
> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>
>>
>> It works if in device tree one specifies the reg-io-width property and
>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>> unusable.
>
> In the case of incorrect DT data like a missing reg-io-width property,
> I would expect it to still fail once the regular console or tty takes
> over from earlycon.
>
>> Also, if the earlycon comes specified from the kernel params, the
>> of_setup_earlycon() is no longer called and the earlycon will be set
>> solely based on the kernel params buffer, thus allowing users to crash
>> the kernel on wrong earlycon definitions.
>
> But that in turn is the same as specifying any other incorrect earlycon.
I don't think you can crash the kernel if you use other earlycon as you
don't make accesses on the 32bit restricted bus. But I agree that if
using the correct earlycon name, and mmio instead mmio32, is equivalent
to not specifying reg-io-width in dt.
>
>> If you think the change is fine, I can amend the commit message with the
>> description from above.
>
> I'm still not convinced we need a special case here when everything else
> just requires passing the correct data.
>
Well, I made this patch because I used a wrong bootargs earlycon
configuration and I ended up crashing the kernel. I couldn't see what
happens as kgdb is not available at that stage. Figuring out what was
going on made me spend some time. I hoped I'll be helpful and spare
others of the same mistakes and wasted time.
I'm ok to drop the patch as well, no pushing here. Please ignore.
Thanks for the review!
Cheers,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-14 14:31 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 14:31 UTC (permalink / raw)
To: Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/14/23 14:19, Arnd Bergmann wrote:
> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>
>>
>> It works if in device tree one specifies the reg-io-width property and
>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>> unusable.
>
> In the case of incorrect DT data like a missing reg-io-width property,
> I would expect it to still fail once the regular console or tty takes
> over from earlycon.
>
>> Also, if the earlycon comes specified from the kernel params, the
>> of_setup_earlycon() is no longer called and the earlycon will be set
>> solely based on the kernel params buffer, thus allowing users to crash
>> the kernel on wrong earlycon definitions.
>
> But that in turn is the same as specifying any other incorrect earlycon.
I don't think you can crash the kernel if you use other earlycon as you
don't make accesses on the 32bit restricted bus. But I agree that if
using the correct earlycon name, and mmio instead mmio32, is equivalent
to not specifying reg-io-width in dt.
>
>> If you think the change is fine, I can amend the commit message with the
>> description from above.
>
> I'm still not convinced we need a special case here when everything else
> just requires passing the correct data.
>
Well, I made this patch because I used a wrong bootargs earlycon
configuration and I ended up crashing the kernel. I couldn't see what
happens as kgdb is not available at that stage. Figuring out what was
going on made me spend some time. I hoped I'll be helpful and spare
others of the same mistakes and wasted time.
I'm ok to drop the patch as well, no pushing here. Please ignore.
Thanks for the review!
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:07 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:07 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
Doesn't it break existing gs101 device tree?
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
(snip)
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-14 15:07 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:07 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
Doesn't it break existing gs101 device tree?
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
(snip)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:12 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:12 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> clock management unit.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
> 2 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> index 3eebc03a309b..ba54c13c55bc 100644
> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -30,14 +30,15 @@ properties:
> - google,gs101-cmu-top
> - google,gs101-cmu-apm
> - google,gs101-cmu-misc
> + - google,gs101-cmu-peric0
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> clock-names:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> "#clock-cells":
> const: 1
> @@ -88,6 +89,26 @@ allOf:
> - const: dout_cmu_misc_bus
> - const: dout_cmu_misc_sss
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: google,gs101-cmu-peric0
> +
> + then:
> + properties:
> + clocks:
> + items:
> + - description: External reference clock (24.576 MHz)
> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> +
> + clock-names:
> + items:
> + - const: oscclk
> + - const: dout_cmu_peric0_bus
> + - const: dout_cmu_peric0_ip
> +
> additionalProperties: false
>
> examples:
> diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> index 21adec22387c..7d7a896416a7 100644
> --- a/include/dt-bindings/clock/google,gs101.h
> +++ b/include/dt-bindings/clock/google,gs101.h
> @@ -389,4 +389,90 @@
> #define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK 73
> #define CLK_GOUT_MISC_XIU_D_MISC_ACLK 74
>
> +/* CMU_PERIC0 */
This comments looks off here. Other than than, LGTM:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> +/* CMU_PERIC0 MUX */
> +#define CLK_MOUT_PERIC0_BUS_USER 1
> +#define CLK_MOUT_PERIC0_I3C_USER 2
> +#define CLK_MOUT_PERIC0_USI0_UART_USER 3
> +#define CLK_MOUT_PERIC0_USI14_USI_USER 4
> +#define CLK_MOUT_PERIC0_USI1_USI_USER 5
> +#define CLK_MOUT_PERIC0_USI2_USI_USER 6
> +#define CLK_MOUT_PERIC0_USI3_USI_USER 7
> +#define CLK_MOUT_PERIC0_USI4_USI_USER 8
> +#define CLK_MOUT_PERIC0_USI5_USI_USER 9
> +#define CLK_MOUT_PERIC0_USI6_USI_USER 10
> +#define CLK_MOUT_PERIC0_USI7_USI_USER 11
> +#define CLK_MOUT_PERIC0_USI8_USI_USER 12
> +
> +/* CMU_PERIC0 Dividers */
> +#define CLK_DOUT_PERIC0_I3C 13
> +#define CLK_DOUT_PERIC0_USI0_UART 14
> +#define CLK_DOUT_PERIC0_USI14_USI 15
> +#define CLK_DOUT_PERIC0_USI1_USI 16
> +#define CLK_DOUT_PERIC0_USI2_USI 17
> +#define CLK_DOUT_PERIC0_USI3_USI 18
> +#define CLK_DOUT_PERIC0_USI4_USI 19
> +#define CLK_DOUT_PERIC0_USI5_USI 20
> +#define CLK_DOUT_PERIC0_USI6_USI 21
> +#define CLK_DOUT_PERIC0_USI7_USI 22
> +#define CLK_DOUT_PERIC0_USI8_USI 23
> +
> +/* CMU_PERIC0 Gates */
> +#define CLK_GOUT_PERIC0_IP 24
> +#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK 25
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK 26
> +#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK 27
> +#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK 28
> +#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK 29
> +#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK 30
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0 31
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1 32
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10 33
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11 34
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12 35
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13 36
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14 37
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15 38
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2 39
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3 40
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4 41
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5 42
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6 43
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7 44
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8 45
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9 46
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0 47
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1 48
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10 49
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11 50
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12 51
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13 52
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14 53
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15 54
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2 55
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3 56
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4 57
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5 58
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6 59
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7 60
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8 61
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9 62
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0 63
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2 64
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0 65
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2 66
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK 67
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK 68
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK 69
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK 70
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK 71
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK 72
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK 73
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK 74
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK 75
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK 76
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK 77
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK 78
> +#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK 79
> +
> #endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-14 15:12 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:12 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> clock management unit.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
> 2 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> index 3eebc03a309b..ba54c13c55bc 100644
> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -30,14 +30,15 @@ properties:
> - google,gs101-cmu-top
> - google,gs101-cmu-apm
> - google,gs101-cmu-misc
> + - google,gs101-cmu-peric0
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> clock-names:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> "#clock-cells":
> const: 1
> @@ -88,6 +89,26 @@ allOf:
> - const: dout_cmu_misc_bus
> - const: dout_cmu_misc_sss
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: google,gs101-cmu-peric0
> +
> + then:
> + properties:
> + clocks:
> + items:
> + - description: External reference clock (24.576 MHz)
> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> +
> + clock-names:
> + items:
> + - const: oscclk
> + - const: dout_cmu_peric0_bus
> + - const: dout_cmu_peric0_ip
> +
> additionalProperties: false
>
> examples:
> diff --git a/include/dt-bindings/clock/google,gs101.h b/include/dt-bindings/clock/google,gs101.h
> index 21adec22387c..7d7a896416a7 100644
> --- a/include/dt-bindings/clock/google,gs101.h
> +++ b/include/dt-bindings/clock/google,gs101.h
> @@ -389,4 +389,90 @@
> #define CLK_GOUT_MISC_WDT_CLUSTER1_PCLK 73
> #define CLK_GOUT_MISC_XIU_D_MISC_ACLK 74
>
> +/* CMU_PERIC0 */
This comments looks off here. Other than than, LGTM:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> +/* CMU_PERIC0 MUX */
> +#define CLK_MOUT_PERIC0_BUS_USER 1
> +#define CLK_MOUT_PERIC0_I3C_USER 2
> +#define CLK_MOUT_PERIC0_USI0_UART_USER 3
> +#define CLK_MOUT_PERIC0_USI14_USI_USER 4
> +#define CLK_MOUT_PERIC0_USI1_USI_USER 5
> +#define CLK_MOUT_PERIC0_USI2_USI_USER 6
> +#define CLK_MOUT_PERIC0_USI3_USI_USER 7
> +#define CLK_MOUT_PERIC0_USI4_USI_USER 8
> +#define CLK_MOUT_PERIC0_USI5_USI_USER 9
> +#define CLK_MOUT_PERIC0_USI6_USI_USER 10
> +#define CLK_MOUT_PERIC0_USI7_USI_USER 11
> +#define CLK_MOUT_PERIC0_USI8_USI_USER 12
> +
> +/* CMU_PERIC0 Dividers */
> +#define CLK_DOUT_PERIC0_I3C 13
> +#define CLK_DOUT_PERIC0_USI0_UART 14
> +#define CLK_DOUT_PERIC0_USI14_USI 15
> +#define CLK_DOUT_PERIC0_USI1_USI 16
> +#define CLK_DOUT_PERIC0_USI2_USI 17
> +#define CLK_DOUT_PERIC0_USI3_USI 18
> +#define CLK_DOUT_PERIC0_USI4_USI 19
> +#define CLK_DOUT_PERIC0_USI5_USI 20
> +#define CLK_DOUT_PERIC0_USI6_USI 21
> +#define CLK_DOUT_PERIC0_USI7_USI 22
> +#define CLK_DOUT_PERIC0_USI8_USI 23
> +
> +/* CMU_PERIC0 Gates */
> +#define CLK_GOUT_PERIC0_IP 24
> +#define CLK_GOUT_PERIC0_PERIC0_CMU_PERIC0_PCLK 25
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_OSCCLK_CLK 26
> +#define CLK_GOUT_PERIC0_D_TZPC_PERIC0_PCLK 27
> +#define CLK_GOUT_PERIC0_GPC_PERIC0_PCLK 28
> +#define CLK_GOUT_PERIC0_GPIO_PERIC0_PCLK 29
> +#define CLK_GOUT_PERIC0_LHM_AXI_P_PERIC0_I_CLK 30
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_0 31
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_1 32
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_10 33
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_11 34
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_12 35
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_13 36
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_14 37
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_15 38
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_2 39
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_3 40
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_4 41
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_5 42
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_6 43
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7 44
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_8 45
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_9 46
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_0 47
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_1 48
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_10 49
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_11 50
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_12 51
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_13 52
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_14 53
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_15 54
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_2 55
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_3 56
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_4 57
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_5 58
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_6 59
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_7 60
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_8 61
> +#define CLK_GOUT_PERIC0_PERIC0_TOP0_PCLK_9 62
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_0 63
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_IPCLK_2 64
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_0 65
> +#define CLK_GOUT_PERIC0_PERIC0_TOP1_PCLK_2 66
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_BUSP_CLK 67
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_I3C_CLK 68
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK 69
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI14_USI_CLK 70
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI1_USI_CLK 71
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI2_USI_CLK 72
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI3_USI_CLK 73
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI4_USI_CLK 74
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI5_USI_CLK 75
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI6_USI_CLK 76
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI7_USI_CLK 77
> +#define CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK 78
> +#define CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK 79
> +
> #endif /* _DT_BINDINGS_CLOCK_GOOGLE_GS101_H */
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:12 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:12 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> index df9c57bca2a8..cc8bba5537b9 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> @@ -33,6 +33,7 @@ properties:
> - const: samsung,exynos7-hsi2c
> - items:
> - enum:
> + - google,gs101-hsi2c
> - samsung,exynos850-hsi2c
> - const: samsung,exynosautov9-hsi2c
> - const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
@ 2023-12-14 15:12 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:12 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> index df9c57bca2a8..cc8bba5537b9 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
> @@ -33,6 +33,7 @@ properties:
> - const: samsung,exynos7-hsi2c
> - items:
> - enum:
> + - google,gs101-hsi2c
> - samsung,exynos850-hsi2c
> - const: samsung,exynosautov9-hsi2c
> - const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:14 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:14 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> GS101 only allows 32-bit register accesses. When using 8-bit reg
> accesses on gs101, a SError Interrupt is raised causing the system
> unusable.
>
> Make reg-io-width a required property and expect for it a value of 4.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 133259ed3a34..cc896d7e2a3d 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -143,6 +143,10 @@ allOf:
> then:
> required:
> - samsung,uart-fifosize
> + - reg-io-width
> + properties:
> + reg-io-width:
> + const: 4
>
> unevaluatedProperties: false
>
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
@ 2023-12-14 15:14 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:14 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> GS101 only allows 32-bit register accesses. When using 8-bit reg
> accesses on gs101, a SError Interrupt is raised causing the system
> unusable.
>
> Make reg-io-width a required property and expect for it a value of 4.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 133259ed3a34..cc896d7e2a3d 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -143,6 +143,10 @@ allOf:
> then:
> required:
> - samsung,uart-fifosize
> + - reg-io-width
> + properties:
> + reg-io-width:
> + const: 4
>
> unevaluatedProperties: false
>
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-14 15:07 ` Sam Protsenko
@ 2023-12-14 15:16 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 15:16 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/14/23 15:07, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>
>
> Doesn't it break existing gs101 device tree?
No, compilation went fine at this point. The TOP gates are not used in
the device tree at this point. And since the bindings patch was just
applied I think we should fix it, so that we avoid name clashes as
described below (I found a clash with a gate from PERIC0).
>
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>
> (snip)
Thanks for the review!
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-14 15:16 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 15:16 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/14/23 15:07, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>
>
> Doesn't it break existing gs101 device tree?
No, compilation went fine at this point. The TOP gates are not used in
the device tree at this point. And since the bindings patch was just
applied I think we should fix it, so that we avoid name clashes as
described below (I found a clash with a gate from PERIC0).
>
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>
> (snip)
Thanks for the review!
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-14 15:16 ` Tudor Ambarus
@ 2023-12-14 15:22 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:22 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 9:16 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/14/23 15:07, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> The gs101 clock names are derived from the clock register names under
> >> some certain rules. In particular, for the gate clocks the following is
> >> documented and expected in the gs101 clock driver:
> >>
> >> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> >> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
> >>
> >> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
> >>
> >
> > Doesn't it break existing gs101 device tree?
>
> No, compilation went fine at this point. The TOP gates are not used in
> the device tree at this point. And since the bindings patch was just
> applied I think we should fix it, so that we avoid name clashes as
> described below (I found a clash with a gate from PERIC0).
>
Ok, in that case feel free to add:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> >
> >> The CMU TOP gate clock names missed to include the required "CMU"
> >> differentiator which will cause name collisions with the gate clock names
> >> of other clock units. Fix the TOP gate clock names and include "CMU" in
> >> their name.
> >>
> >> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >
> > (snip)
>
> Thanks for the review!
> ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-14 15:22 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:22 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 9:16 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/14/23 15:07, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> The gs101 clock names are derived from the clock register names under
> >> some certain rules. In particular, for the gate clocks the following is
> >> documented and expected in the gs101 clock driver:
> >>
> >> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> >> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
> >>
> >> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
> >>
> >
> > Doesn't it break existing gs101 device tree?
>
> No, compilation went fine at this point. The TOP gates are not used in
> the device tree at this point. And since the bindings patch was just
> applied I think we should fix it, so that we avoid name clashes as
> described below (I found a clash with a gate from PERIC0).
>
Ok, in that case feel free to add:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> >
> >> The CMU TOP gate clock names missed to include the required "CMU"
> >> differentiator which will cause name collisions with the gate clock names
> >> of other clock units. Fix the TOP gate clock names and include "CMU" in
> >> their name.
> >>
> >> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >
> > (snip)
>
> Thanks for the review!
> ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:37 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:37 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> which then makes the system hang. To prevent this, mark
> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> accordingly when tested.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> drivers/clk/samsung/clk-gs101.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index 3d194520b05e..08d80fca9cd6 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> 21, 0, 0),
> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
This clock doesn't seem like a leaf clock. It's also not a bus clock.
Leaving it always running makes the whole PERIC0 CMU clocked, which
usually should be avoided. Is it possible that the system freezes
because some other clock (which depends on peric0_ip) gets disabled as
a consequence of disabling peric0_ip? Maybe it's some leaf clock which
is not implemented yet in the clock driver? Just looks weird to me
that the system hangs because of CMU IP clock disablement. It's
usually something much more specific.
> GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
> "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
> 21, 0, 0),
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-14 15:37 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:37 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> which then makes the system hang. To prevent this, mark
> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> accordingly when tested.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> drivers/clk/samsung/clk-gs101.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index 3d194520b05e..08d80fca9cd6 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> 21, 0, 0),
> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
This clock doesn't seem like a leaf clock. It's also not a bus clock.
Leaving it always running makes the whole PERIC0 CMU clocked, which
usually should be avoided. Is it possible that the system freezes
because some other clock (which depends on peric0_ip) gets disabled as
a consequence of disabling peric0_ip? Maybe it's some leaf clock which
is not implemented yet in the clock driver? Just looks weird to me
that the system hangs because of CMU IP clock disablement. It's
usually something much more specific.
> GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
> "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
> 21, 0, 0),
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:39 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:39 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Enable the cmu-peric0 clock controller. It feeds USI and I3c.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 9747cb3fa03a..d0b0ad70c6ba 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
> };
> };
>
> + cmu_peric0: clock-controller@10800000 {
> + compatible = "google,gs101-cmu-peric0";
> + reg = <0x10800000 0x4000>;
> + #clock-cells = <1>;
> + clocks = <&ext_24_5m>,
> + <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
> + <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
> + clock-names = "oscclk",
> + "dout_cmu_peric0_bus",
I'd pull this line to the above line. Other than that:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> + "dout_cmu_peric0_ip";
> + };
> +
> sysreg_peric0: syscon@10820000 {
> compatible = "google,gs101-peric0-sysreg", "syscon";
> reg = <0x10820000 0x10000>;
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
@ 2023-12-14 15:39 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:39 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Enable the cmu-peric0 clock controller. It feeds USI and I3c.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index 9747cb3fa03a..d0b0ad70c6ba 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
> };
> };
>
> + cmu_peric0: clock-controller@10800000 {
> + compatible = "google,gs101-cmu-peric0";
> + reg = <0x10800000 0x4000>;
> + #clock-cells = <1>;
> + clocks = <&ext_24_5m>,
> + <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
> + <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
> + clock-names = "oscclk",
> + "dout_cmu_peric0_bus",
I'd pull this line to the above line. Other than that:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> + "dout_cmu_peric0_ip";
> + };
> +
> sysreg_peric0: syscon@10820000 {
> compatible = "google,gs101-peric0-sysreg", "syscon";
> reg = <0x10820000 0x10000>;
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:42 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Get rid of the dummy clock and start using the cmu_peric0 clocks
> for the usi_uart and serial_0 nodes.
>
> Tested the serial at 115200, 1000000 and 3000000 baudrates,
> everthing went fine.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index d0b0ad70c6ba..ffb7b4d89a8c 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
> };
> };
>
> - /* TODO replace with CCF clock */
> - dummy_clk: clock-3 {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <12345>;
> - clock-output-names = "pclk";
> - };
> -
> /* ect node is required to be present by bootloader */
> ect {
> };
> @@ -369,7 +361,8 @@ usi_uart: usi@10a000c0 {
> ranges;
> #address-cells = <1>;
> #size-cells = <1>;
> - clocks = <&dummy_clk>, <&dummy_clk>;
> + clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> + <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
Why using DIV clock here? Usually all leaf clocks are GATE clocks (at
least it's so in Exynos850).
> clock-names = "pclk", "ipclk";
> samsung,sysreg = <&sysreg_peric0 0x1020>;
> samsung,mode = <USI_V2_UART>;
> @@ -381,7 +374,8 @@ serial_0: serial@10a00000 {
> reg-io-width = <4>;
> interrupts = <GIC_SPI 634
> IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> + clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> + <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
Ditto.
> clock-names = "uart", "clk_uart_baud0";
> samsung,uart-fifosize = <256>;
> status = "disabled";
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks
@ 2023-12-14 15:42 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Get rid of the dummy clock and start using the cmu_peric0 clocks
> for the usi_uart and serial_0 nodes.
>
> Tested the serial at 115200, 1000000 and 3000000 baudrates,
> everthing went fine.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index d0b0ad70c6ba..ffb7b4d89a8c 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -180,14 +180,6 @@ HERA_CPU_SLEEP: cpu-hera-sleep {
> };
> };
>
> - /* TODO replace with CCF clock */
> - dummy_clk: clock-3 {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <12345>;
> - clock-output-names = "pclk";
> - };
> -
> /* ect node is required to be present by bootloader */
> ect {
> };
> @@ -369,7 +361,8 @@ usi_uart: usi@10a000c0 {
> ranges;
> #address-cells = <1>;
> #size-cells = <1>;
> - clocks = <&dummy_clk>, <&dummy_clk>;
> + clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> + <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
Why using DIV clock here? Usually all leaf clocks are GATE clocks (at
least it's so in Exynos850).
> clock-names = "pclk", "ipclk";
> samsung,sysreg = <&sysreg_peric0 0x1020>;
> samsung,mode = <USI_V2_UART>;
> @@ -381,7 +374,8 @@ serial_0: serial@10a00000 {
> reg-io-width = <4>;
> interrupts = <GIC_SPI 634
> IRQ_TYPE_LEVEL_HIGH 0>;
> - clocks = <&dummy_clk 0>, <&dummy_clk 0>;
> + clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI0_UART_CLK>,
> + <&cmu_peric0 CLK_DOUT_PERIC0_USI0_UART>;
Ditto.
> clock-names = "uart", "clk_uart_baud0";
> samsung,uart-fifosize = <256>;
> status = "disabled";
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:51 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:51 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dtsi file.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index ffb7b4d89a8c..4ea1b180cd0a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl@10840000 {
> interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> + usi8: usi@109700c0 {
> + compatible = "google,gs101-usi",
> + "samsung,exynos850-usi";
> + reg = <0x109700c0 0x20>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
Are you sure this is a leaf clock? Usually it's a GATE clock, not a DIV one.
> + <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
Because of following letter-for-letter the crazy TRM clock namings,
now it's not possible to keep 80 characters length in a sane way :(
> + clock-names = "pclk", "ipclk";
> + samsung,sysreg = <&sysreg_peric0 0x101c>;
samsung,mode is not needed in this case?
> + status = "disabled";
> +
> + hsi2c_8: i2c@10970000 {
> + compatible = "google,gs101-hsi2c",
> + "samsung,exynosautov9-hsi2c";
> + reg = <0x10970000 0xc0>;
> + interrupts = <GIC_SPI 642
> + IRQ_TYPE_LEVEL_HIGH 0>;
IRQ type constant can fit the previous line.
> + clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
> + <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> + clock-names = "hsi2c", "hsi2c_pclk";
> + status = "disabled";
Pinctrl properties are not needed for this node?
> + };
> + };
> +
> usi_uart: usi@10a000c0 {
> compatible = "google,gs101-usi",
> "samsung,exynos850-usi";
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
@ 2023-12-14 15:51 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:51 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dtsi file.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index ffb7b4d89a8c..4ea1b180cd0a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl@10840000 {
> interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> + usi8: usi@109700c0 {
> + compatible = "google,gs101-usi",
> + "samsung,exynos850-usi";
> + reg = <0x109700c0 0x20>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
Are you sure this is a leaf clock? Usually it's a GATE clock, not a DIV one.
> + <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
Because of following letter-for-letter the crazy TRM clock namings,
now it's not possible to keep 80 characters length in a sane way :(
> + clock-names = "pclk", "ipclk";
> + samsung,sysreg = <&sysreg_peric0 0x101c>;
samsung,mode is not needed in this case?
> + status = "disabled";
> +
> + hsi2c_8: i2c@10970000 {
> + compatible = "google,gs101-hsi2c",
> + "samsung,exynosautov9-hsi2c";
> + reg = <0x10970000 0xc0>;
> + interrupts = <GIC_SPI 642
> + IRQ_TYPE_LEVEL_HIGH 0>;
IRQ type constant can fit the previous line.
> + clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
> + <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> + clock-names = "hsi2c", "hsi2c_pclk";
> + status = "disabled";
Pinctrl properties are not needed for this node?
> + };
> + };
> +
> usi_uart: usi@10a000c0 {
> compatible = "google,gs101-usi",
> "samsung,exynos850-usi";
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 15:55 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:55 UTC (permalink / raw)
To: Tudor Ambarus, krzysztof.kozlowski+dt
Cc: peter.griffin, robh+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, andre.draszik,
saravanak, willmcvicker, linux-arm-kernel, linux-samsung-soc,
linux-clk, devicetree, linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Enable the eeprom found on the battery connector.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> .../boot/dts/exynos/google/gs101-oriole.dts | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> index 4a71f752200d..11b299d21c5d 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> @@ -63,6 +63,19 @@ &ext_200m {
> clock-frequency = <200000000>;
> };
>
> +&hsi2c_8 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&hsi2c8_bus>;
> + #address-cells = <1>;
> + #size-cells = <0>;
Not sure if those 4 above properties belong in board's dts or in SoC's
dtsi. Krzysztof, what do you think?
Other than that:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> + status = "okay";
> +
> + eeprom: eeprom@50 {
> + compatible = "atmel,24c08";
> + reg = <0x50>;
> + };
> +};
> +
> &pinctrl_far_alive {
> key_voldown: key-voldown-pins {
> samsung,pins = "gpa7-3";
> @@ -99,6 +112,11 @@ &usi_uart {
> status = "okay";
> };
>
> +&usi8 {
> + samsung,mode = <USI_V2_I2C>;
> + status = "okay";
> +};
> +
> &watchdog_cl0 {
> timeout-sec = <30>;
> status = "okay";
> --
> 2.43.0.472.g3155946c3a-goog
>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
@ 2023-12-14 15:55 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 15:55 UTC (permalink / raw)
To: Tudor Ambarus, krzysztof.kozlowski+dt
Cc: peter.griffin, robh+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, andre.draszik,
saravanak, willmcvicker, linux-arm-kernel, linux-samsung-soc,
linux-clk, devicetree, linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Enable the eeprom found on the battery connector.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> .../boot/dts/exynos/google/gs101-oriole.dts | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> index 4a71f752200d..11b299d21c5d 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
> @@ -63,6 +63,19 @@ &ext_200m {
> clock-frequency = <200000000>;
> };
>
> +&hsi2c_8 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&hsi2c8_bus>;
> + #address-cells = <1>;
> + #size-cells = <0>;
Not sure if those 4 above properties belong in board's dts or in SoC's
dtsi. Krzysztof, what do you think?
Other than that:
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
> + status = "okay";
> +
> + eeprom: eeprom@50 {
> + compatible = "atmel,24c08";
> + reg = <0x50>;
> + };
> +};
> +
> &pinctrl_far_alive {
> key_voldown: key-voldown-pins {
> samsung,pins = "gpa7-3";
> @@ -99,6 +112,11 @@ &usi_uart {
> status = "okay";
> };
>
> +&usi8 {
> + samsung,mode = <USI_V2_I2C>;
> + status = "okay";
> +};
> +
> &watchdog_cl0 {
> timeout-sec = <30>;
> status = "okay";
> --
> 2.43.0.472.g3155946c3a-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 15:37 ` Sam Protsenko
@ 2023-12-14 16:01 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 16:01 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/14/23 15:37, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>> which then makes the system hang. To prevent this, mark
>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>> accordingly when tested.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> drivers/clk/samsung/clk-gs101.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>> index 3d194520b05e..08d80fca9cd6 100644
>> --- a/drivers/clk/samsung/clk-gs101.c
>> +++ b/drivers/clk/samsung/clk-gs101.c
>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>> 21, 0, 0),
>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>
> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> Leaving it always running makes the whole PERIC0 CMU clocked, which
> usually should be avoided. Is it possible that the system freezes
> because some other clock (which depends on peric0_ip) gets disabled as
> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> is not implemented yet in the clock driver? Just looks weird to me
> that the system hangs because of CMU IP clock disablement. It's
> usually something much more specific.
The system hang happened when I tested USI8 in I2C configuration with an
eeprom. After the eeprom is read the leaf gate clock that gets disabled
is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
disablement which makes the system hang. Either marking the CMU_TOP gate
clock as critical (as I did in this patch) or marking the leaf PERIC0
gate clock as critical, gets rid of the system hang. Did I choose wrong?
Thanks,
ta
>
>> GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
>> "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
>> 21, 0, 0),
>> --
>> 2.43.0.472.g3155946c3a-goog
>>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-14 16:01 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 16:01 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/14/23 15:37, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>> which then makes the system hang. To prevent this, mark
>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>> accordingly when tested.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> drivers/clk/samsung/clk-gs101.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>> index 3d194520b05e..08d80fca9cd6 100644
>> --- a/drivers/clk/samsung/clk-gs101.c
>> +++ b/drivers/clk/samsung/clk-gs101.c
>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>> 21, 0, 0),
>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>
> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> Leaving it always running makes the whole PERIC0 CMU clocked, which
> usually should be avoided. Is it possible that the system freezes
> because some other clock (which depends on peric0_ip) gets disabled as
> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> is not implemented yet in the clock driver? Just looks weird to me
> that the system hangs because of CMU IP clock disablement. It's
> usually something much more specific.
The system hang happened when I tested USI8 in I2C configuration with an
eeprom. After the eeprom is read the leaf gate clock that gets disabled
is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
disablement which makes the system hang. Either marking the CMU_TOP gate
clock as critical (as I did in this patch) or marking the leaf PERIC0
gate clock as critical, gets rid of the system hang. Did I choose wrong?
Thanks,
ta
>
>> GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
>> "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
>> 21, 0, 0),
>> --
>> 2.43.0.472.g3155946c3a-goog
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-14 16:04 ` Peter Griffin
-1 siblings, 0 replies; 122+ messages in thread
From: Peter Griffin @ 2023-12-14 16:04 UTC (permalink / raw)
To: Tudor Ambarus
Cc: robh+dt, krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt,
andi.shyti, alim.akhtar, gregkh, jirislaby, catalin.marinas,
will, s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi Tudor,
On Thu, 14 Dec 2023 at 10:52, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
[...]
Thanks for spotting this inconsistency on the cmu_top gates and fixing it!
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-14 16:04 ` Peter Griffin
0 siblings, 0 replies; 122+ messages in thread
From: Peter Griffin @ 2023-12-14 16:04 UTC (permalink / raw)
To: Tudor Ambarus
Cc: robh+dt, krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt,
andi.shyti, alim.akhtar, gregkh, jirislaby, catalin.marinas,
will, s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi Tudor,
On Thu, 14 Dec 2023 at 10:52, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
[...]
Thanks for spotting this inconsistency on the cmu_top gates and fixing it!
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 16:01 ` Tudor Ambarus
@ 2023-12-14 16:09 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 16:09 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/14/23 15:37, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >> which then makes the system hang. To prevent this, mark
> >> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >> accordingly when tested.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >> drivers/clk/samsung/clk-gs101.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >> index 3d194520b05e..08d80fca9cd6 100644
> >> --- a/drivers/clk/samsung/clk-gs101.c
> >> +++ b/drivers/clk/samsung/clk-gs101.c
> >> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >> 21, 0, 0),
> >> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >
> > This clock doesn't seem like a leaf clock. It's also not a bus clock.
> > Leaving it always running makes the whole PERIC0 CMU clocked, which
> > usually should be avoided. Is it possible that the system freezes
> > because some other clock (which depends on peric0_ip) gets disabled as
> > a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> > is not implemented yet in the clock driver? Just looks weird to me
> > that the system hangs because of CMU IP clock disablement. It's
> > usually something much more specific.
>
> The system hang happened when I tested USI8 in I2C configuration with an
> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> disablement which makes the system hang. Either marking the CMU_TOP gate
> clock as critical (as I did in this patch) or marking the leaf PERIC0
> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>
Did you already implement 100% of clocks in CMU_PERIC0? If no, there
is a chance some other leaf clock (which is not implemented yet in
your driver) gets disabled as a result of PERIC0_IP disablement, which
might actually lead to that hang you observe. Usually it's some
meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
and the corresponding comments I left there, maybe it'll give you more
particular idea about what to look for. Yes, making the whole CMU
always running without understanding why (i.e. because of which
particular leaf clock) might not be the best way of handling this
issue. I might be mistaken, but at least please check if you
implemented all clocks for PERIC0 first and if making some meaningful
leaf clock critical makes more sense.
> Thanks,
> ta
> >
> >> GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
> >> "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
> >> 21, 0, 0),
> >> --
> >> 2.43.0.472.g3155946c3a-goog
> >>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-14 16:09 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 16:09 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/14/23 15:37, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >> which then makes the system hang. To prevent this, mark
> >> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >> accordingly when tested.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >> drivers/clk/samsung/clk-gs101.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >> index 3d194520b05e..08d80fca9cd6 100644
> >> --- a/drivers/clk/samsung/clk-gs101.c
> >> +++ b/drivers/clk/samsung/clk-gs101.c
> >> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >> 21, 0, 0),
> >> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >
> > This clock doesn't seem like a leaf clock. It's also not a bus clock.
> > Leaving it always running makes the whole PERIC0 CMU clocked, which
> > usually should be avoided. Is it possible that the system freezes
> > because some other clock (which depends on peric0_ip) gets disabled as
> > a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> > is not implemented yet in the clock driver? Just looks weird to me
> > that the system hangs because of CMU IP clock disablement. It's
> > usually something much more specific.
>
> The system hang happened when I tested USI8 in I2C configuration with an
> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> disablement which makes the system hang. Either marking the CMU_TOP gate
> clock as critical (as I did in this patch) or marking the leaf PERIC0
> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>
Did you already implement 100% of clocks in CMU_PERIC0? If no, there
is a chance some other leaf clock (which is not implemented yet in
your driver) gets disabled as a result of PERIC0_IP disablement, which
might actually lead to that hang you observe. Usually it's some
meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
and the corresponding comments I left there, maybe it'll give you more
particular idea about what to look for. Yes, making the whole CMU
always running without understanding why (i.e. because of which
particular leaf clock) might not be the best way of handling this
issue. I might be mistaken, but at least please check if you
implemented all clocks for PERIC0 first and if making some meaningful
leaf clock critical makes more sense.
> Thanks,
> ta
> >
> >> GATE(CLK_GOUT_CMU_PERIC1_BUS, "gout_cmu_peric1_bus",
> >> "mout_cmu_peric1_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC1_BUS,
> >> 21, 0, 0),
> >> --
> >> 2.43.0.472.g3155946c3a-goog
> >>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 16:09 ` Sam Protsenko
@ 2023-12-14 16:15 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 16:15 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/14/23 16:09, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>>
>>
>> On 12/14/23 15:37, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>> which then makes the system hang. To prevent this, mark
>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>> accordingly when tested.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> ---
>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>> 21, 0, 0),
>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>
>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>> usually should be avoided. Is it possible that the system freezes
>>> because some other clock (which depends on peric0_ip) gets disabled as
>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>> is not implemented yet in the clock driver? Just looks weird to me
>>> that the system hangs because of CMU IP clock disablement. It's
>>> usually something much more specific.
>>
>> The system hang happened when I tested USI8 in I2C configuration with an
>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>> disablement which makes the system hang. Either marking the CMU_TOP gate
>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>
>
> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
yes.
> is a chance some other leaf clock (which is not implemented yet in
> your driver) gets disabled as a result of PERIC0_IP disablement, which
> might actually lead to that hang you observe. Usually it's some
> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> and the corresponding comments I left there, maybe it'll give you more
> particular idea about what to look for. Yes, making the whole CMU
> always running without understanding why (i.e. because of which
> particular leaf clock) might not be the best way of handling this
because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> issue. I might be mistaken, but at least please check if you
> implemented all clocks for PERIC0 first and if making some meaningful
> leaf clock critical makes more sense.
>
Thanks,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-14 16:15 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-14 16:15 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/14/23 16:09, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>>
>>
>> On 12/14/23 15:37, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>> which then makes the system hang. To prevent this, mark
>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>> accordingly when tested.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> ---
>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>> 21, 0, 0),
>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>
>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>> usually should be avoided. Is it possible that the system freezes
>>> because some other clock (which depends on peric0_ip) gets disabled as
>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>> is not implemented yet in the clock driver? Just looks weird to me
>>> that the system hangs because of CMU IP clock disablement. It's
>>> usually something much more specific.
>>
>> The system hang happened when I tested USI8 in I2C configuration with an
>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>> disablement which makes the system hang. Either marking the CMU_TOP gate
>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>
>
> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
yes.
> is a chance some other leaf clock (which is not implemented yet in
> your driver) gets disabled as a result of PERIC0_IP disablement, which
> might actually lead to that hang you observe. Usually it's some
> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> and the corresponding comments I left there, maybe it'll give you more
> particular idea about what to look for. Yes, making the whole CMU
> always running without understanding why (i.e. because of which
> particular leaf clock) might not be the best way of handling this
because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> issue. I might be mistaken, but at least please check if you
> implemented all clocks for PERIC0 first and if making some meaningful
> leaf clock critical makes more sense.
>
Thanks,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 16:15 ` Tudor Ambarus
@ 2023-12-14 16:43 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 16:43 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/14/23 16:09, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >>
> >>
> >> On 12/14/23 15:37, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>
> >>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>> which then makes the system hang. To prevent this, mark
> >>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>> accordingly when tested.
> >>>>
> >>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >>>> ---
> >>>> drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>> 21, 0, 0),
> >>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>
> >>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>> usually should be avoided. Is it possible that the system freezes
> >>> because some other clock (which depends on peric0_ip) gets disabled as
> >>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>> is not implemented yet in the clock driver? Just looks weird to me
> >>> that the system hangs because of CMU IP clock disablement. It's
> >>> usually something much more specific.
> >>
> >> The system hang happened when I tested USI8 in I2C configuration with an
> >> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >> disablement which makes the system hang. Either marking the CMU_TOP gate
> >> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>
> >
> > Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>
> yes.
Ok. Are there any other CMUs (perhaps not implemented yet) which
consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
clocks derived from it? If so, is there a chance some particular leaf
clock in those CMUs actually renders the system frozen when disabled
as a consequence of disabling PERIC0_IP, and would explain better why
the freeze happens?
For now I think it's ok to have that CLK_IS_CRITICAL flag here,
because as you said you implemented all clocks in this CMU and neither
of those looks like a critical one. But I'd advice to add a TODO
comment saying it's probably a temporary solution before actual leaf
clock which leads to freeze is identified (which probably resides in
some other not implemented yet CMU).
>
> > is a chance some other leaf clock (which is not implemented yet in
> > your driver) gets disabled as a result of PERIC0_IP disablement, which
> > might actually lead to that hang you observe. Usually it's some
> > meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> > clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> > and the corresponding comments I left there, maybe it'll give you more
> > particular idea about what to look for. Yes, making the whole CMU
> > always running without understanding why (i.e. because of which
> > particular leaf clock) might not be the best way of handling this
>
> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
That's not a root cause here. And I think PERIC0_IP is neither.
>
> > issue. I might be mistaken, but at least please check if you
> > implemented all clocks for PERIC0 first and if making some meaningful
> > leaf clock critical makes more sense.
> >
>
> Thanks,
> ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-14 16:43 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-14 16:43 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/14/23 16:09, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >>
> >>
> >> On 12/14/23 15:37, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>
> >>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>> which then makes the system hang. To prevent this, mark
> >>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>> accordingly when tested.
> >>>>
> >>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >>>> ---
> >>>> drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>> 21, 0, 0),
> >>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>
> >>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>> usually should be avoided. Is it possible that the system freezes
> >>> because some other clock (which depends on peric0_ip) gets disabled as
> >>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>> is not implemented yet in the clock driver? Just looks weird to me
> >>> that the system hangs because of CMU IP clock disablement. It's
> >>> usually something much more specific.
> >>
> >> The system hang happened when I tested USI8 in I2C configuration with an
> >> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >> disablement which makes the system hang. Either marking the CMU_TOP gate
> >> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>
> >
> > Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>
> yes.
Ok. Are there any other CMUs (perhaps not implemented yet) which
consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
clocks derived from it? If so, is there a chance some particular leaf
clock in those CMUs actually renders the system frozen when disabled
as a consequence of disabling PERIC0_IP, and would explain better why
the freeze happens?
For now I think it's ok to have that CLK_IS_CRITICAL flag here,
because as you said you implemented all clocks in this CMU and neither
of those looks like a critical one. But I'd advice to add a TODO
comment saying it's probably a temporary solution before actual leaf
clock which leads to freeze is identified (which probably resides in
some other not implemented yet CMU).
>
> > is a chance some other leaf clock (which is not implemented yet in
> > your driver) gets disabled as a result of PERIC0_IP disablement, which
> > might actually lead to that hang you observe. Usually it's some
> > meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> > clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> > and the corresponding comments I left there, maybe it'll give you more
> > particular idea about what to look for. Yes, making the whole CMU
> > always running without understanding why (i.e. because of which
> > particular leaf clock) might not be the best way of handling this
>
> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
That's not a root cause here. And I think PERIC0_IP is neither.
>
> > issue. I might be mistaken, but at least please check if you
> > implemented all clocks for PERIC0 first and if making some meaningful
> > leaf clock critical makes more sense.
> >
>
> Thanks,
> ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-15 7:58 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 7:58 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> GS101 only allows 32-bit register accesses. When using 8-bit reg
> accesses on gs101, a SError Interrupt is raised causing the system
> unusable.
>
> Make reg-io-width a required property and expect for it a value of 4.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 133259ed3a34..cc896d7e2a3d 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -143,6 +143,10 @@ allOf:
> then:
> required:
> - samsung,uart-fifosize
> + - reg-io-width
> + properties:
> + reg-io-width:
> + const: 4
If all your ports are like this, then I say this is compatible-specific.
Make it here "reg-io-width: false" and set in the driver proper type in
s3c24xx_serial_init_port_default() (or new function).
Although maybe let's first resolve discussion of next patch.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property
@ 2023-12-15 7:58 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 7:58 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> GS101 only allows 32-bit register accesses. When using 8-bit reg
> accesses on gs101, a SError Interrupt is raised causing the system
> unusable.
>
> Make reg-io-width a required property and expect for it a value of 4.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> index 133259ed3a34..cc896d7e2a3d 100644
> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
> @@ -143,6 +143,10 @@ allOf:
> then:
> required:
> - samsung,uart-fifosize
> + - reg-io-width
> + properties:
> + reg-io-width:
> + const: 4
If all your ports are like this, then I say this is compatible-specific.
Make it here "reg-io-width: false" and set in the driver proper type in
s3c24xx_serial_init_port_default() (or new function).
Although maybe let's first resolve discussion of next patch.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-14 14:31 ` Tudor Ambarus
@ 2023-12-15 8:01 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:01 UTC (permalink / raw)
To: Tudor Ambarus, Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 14/12/2023 15:31, Tudor Ambarus wrote:
>
>
> On 12/14/23 14:19, Arnd Bergmann wrote:
>> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>>
>>>
>>> It works if in device tree one specifies the reg-io-width property and
>>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>>> unusable.
>>
>> In the case of incorrect DT data like a missing reg-io-width property,
>> I would expect it to still fail once the regular console or tty takes
>> over from earlycon.
>>
>>> Also, if the earlycon comes specified from the kernel params, the
>>> of_setup_earlycon() is no longer called and the earlycon will be set
>>> solely based on the kernel params buffer, thus allowing users to crash
>>> the kernel on wrong earlycon definitions.
>>
>> But that in turn is the same as specifying any other incorrect earlycon.
>
> I don't think you can crash the kernel if you use other earlycon as you
> don't make accesses on the 32bit restricted bus. But I agree that if
> using the correct earlycon name, and mmio instead mmio32, is equivalent
> to not specifying reg-io-width in dt.
>
>>
>>> If you think the change is fine, I can amend the commit message with the
>>> description from above.
>>
>> I'm still not convinced we need a special case here when everything else
>> just requires passing the correct data.
We shouldn't need any data from DT for this case, because this property
apparently can be inferred from the compatible. IOW, GS101 SoC requires
reg-io-width=4, everywhere, for each node, thus there is no need to
specify this property. It should be deduced from the compatible.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-15 8:01 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:01 UTC (permalink / raw)
To: Tudor Ambarus, Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 14/12/2023 15:31, Tudor Ambarus wrote:
>
>
> On 12/14/23 14:19, Arnd Bergmann wrote:
>> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>>
>>>
>>> It works if in device tree one specifies the reg-io-width property and
>>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>>> unusable.
>>
>> In the case of incorrect DT data like a missing reg-io-width property,
>> I would expect it to still fail once the regular console or tty takes
>> over from earlycon.
>>
>>> Also, if the earlycon comes specified from the kernel params, the
>>> of_setup_earlycon() is no longer called and the earlycon will be set
>>> solely based on the kernel params buffer, thus allowing users to crash
>>> the kernel on wrong earlycon definitions.
>>
>> But that in turn is the same as specifying any other incorrect earlycon.
>
> I don't think you can crash the kernel if you use other earlycon as you
> don't make accesses on the 32bit restricted bus. But I agree that if
> using the correct earlycon name, and mmio instead mmio32, is equivalent
> to not specifying reg-io-width in dt.
>
>>
>>> If you think the change is fine, I can amend the commit message with the
>>> description from above.
>>
>> I'm still not convinced we need a special case here when everything else
>> just requires passing the correct data.
We shouldn't need any data from DT for this case, because this property
apparently can be inferred from the compatible. IOW, GS101 SoC requires
reg-io-width=4, everywhere, for each node, thus there is no need to
specify this property. It should be deduced from the compatible.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
2023-12-14 15:39 ` Sam Protsenko
@ 2023-12-15 8:02 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:02 UTC (permalink / raw)
To: Sam Protsenko, Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 16:39, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Enable the cmu-peric0 clock controller. It feeds USI and I3c.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> index 9747cb3fa03a..d0b0ad70c6ba 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> @@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
>> };
>> };
>>
>> + cmu_peric0: clock-controller@10800000 {
>> + compatible = "google,gs101-cmu-peric0";
>> + reg = <0x10800000 0x4000>;
>> + #clock-cells = <1>;
>> + clocks = <&ext_24_5m>,
>> + <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
>> + <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
>> + clock-names = "oscclk",
>> + "dout_cmu_peric0_bus",
>
> I'd pull this line to the above line. Other than that:
>
No, it's fine. If clocks span over multiple lines (one clock per line),
the names should follow in general. It's easier to read and match entries.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller
@ 2023-12-15 8:02 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:02 UTC (permalink / raw)
To: Sam Protsenko, Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 16:39, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Enable the cmu-peric0 clock controller. It feeds USI and I3c.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> index 9747cb3fa03a..d0b0ad70c6ba 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
>> @@ -339,6 +339,18 @@ ppi_cluster2: interrupt-partition-2 {
>> };
>> };
>>
>> + cmu_peric0: clock-controller@10800000 {
>> + compatible = "google,gs101-cmu-peric0";
>> + reg = <0x10800000 0x4000>;
>> + #clock-cells = <1>;
>> + clocks = <&ext_24_5m>,
>> + <&cmu_top CLK_DOUT_CMU_PERIC0_BUS>,
>> + <&cmu_top CLK_DOUT_CMU_PERIC0_IP>;
>> + clock-names = "oscclk",
>> + "dout_cmu_peric0_bus",
>
> I'd pull this line to the above line. Other than that:
>
No, it's fine. If clocks span over multiple lines (one clock per line),
the names should follow in general. It's easier to read and match entries.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-15 8:04 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:04 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dtsi file.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index ffb7b4d89a8c..4ea1b180cd0a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl@10840000 {
> interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> + usi8: usi@109700c0 {
> + compatible = "google,gs101-usi",
> + "samsung,exynos850-usi";
> + reg = <0x109700c0 0x20>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
> + <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> + clock-names = "pclk", "ipclk";
> + samsung,sysreg = <&sysreg_peric0 0x101c>;
> + status = "disabled";
> +
> + hsi2c_8: i2c@10970000 {
> + compatible = "google,gs101-hsi2c",
> + "samsung,exynosautov9-hsi2c";
> + reg = <0x10970000 0xc0>;
> + interrupts = <GIC_SPI 642
> + IRQ_TYPE_LEVEL_HIGH 0>;
This can be in one line. Limit of 80 is not a hard-limit. It can be
violated if it improves readability. Especially if is about 1 character
only.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration
@ 2023-12-15 8:04 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:04 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dtsi file.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 26 ++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> index ffb7b4d89a8c..4ea1b180cd0a 100644
> --- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> +++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
> @@ -354,6 +354,32 @@ pinctrl_peric0: pinctrl@10840000 {
> interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
> };
>
> + usi8: usi@109700c0 {
> + compatible = "google,gs101-usi",
> + "samsung,exynos850-usi";
> + reg = <0x109700c0 0x20>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <&cmu_peric0 CLK_DOUT_PERIC0_USI8_USI>,
> + <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
> + clock-names = "pclk", "ipclk";
> + samsung,sysreg = <&sysreg_peric0 0x101c>;
> + status = "disabled";
> +
> + hsi2c_8: i2c@10970000 {
> + compatible = "google,gs101-hsi2c",
> + "samsung,exynosautov9-hsi2c";
> + reg = <0x10970000 0xc0>;
> + interrupts = <GIC_SPI 642
> + IRQ_TYPE_LEVEL_HIGH 0>;
This can be in one line. Limit of 80 is not a hard-limit. It can be
violated if it improves readability. Especially if is about 1 character
only.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
2023-12-14 15:55 ` Sam Protsenko
@ 2023-12-15 8:07 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:07 UTC (permalink / raw)
To: Sam Protsenko, Tudor Ambarus, krzysztof.kozlowski+dt
Cc: peter.griffin, robh+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, andre.draszik,
saravanak, willmcvicker, linux-arm-kernel, linux-samsung-soc,
linux-clk, devicetree, linux-kernel, linux-i2c, linux-serial
On 14/12/2023 16:55, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Enable the eeprom found on the battery connector.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> .../boot/dts/exynos/google/gs101-oriole.dts | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> index 4a71f752200d..11b299d21c5d 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> @@ -63,6 +63,19 @@ &ext_200m {
>> clock-frequency = <200000000>;
>> };
>>
>> +&hsi2c_8 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&hsi2c8_bus>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> Not sure if those 4 above properties belong in board's dts or in SoC's
> dtsi. Krzysztof, what do you think?
The cells should be in DTSI, because you cannot have an enabled i2c bus
without nodes in normal cases. The not-normal case is incomplete
description, which does not happen here.
The pinctrls I guess as well in DTSI, because you do not customize the
pins in the DTS. IOW, if the pinctrl nodes are coming from shared
pinctrl.DTSI, then pinctrl-0/names stay in DTSI as well.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole
@ 2023-12-15 8:07 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:07 UTC (permalink / raw)
To: Sam Protsenko, Tudor Ambarus, krzysztof.kozlowski+dt
Cc: peter.griffin, robh+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, andre.draszik,
saravanak, willmcvicker, linux-arm-kernel, linux-samsung-soc,
linux-clk, devicetree, linux-kernel, linux-i2c, linux-serial
On 14/12/2023 16:55, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 4:53 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Enable the eeprom found on the battery connector.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> .../boot/dts/exynos/google/gs101-oriole.dts | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> index 4a71f752200d..11b299d21c5d 100644
>> --- a/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> +++ b/arch/arm64/boot/dts/exynos/google/gs101-oriole.dts
>> @@ -63,6 +63,19 @@ &ext_200m {
>> clock-frequency = <200000000>;
>> };
>>
>> +&hsi2c_8 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&hsi2c8_bus>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> Not sure if those 4 above properties belong in board's dts or in SoC's
> dtsi. Krzysztof, what do you think?
The cells should be in DTSI, because you cannot have an enabled i2c bus
without nodes in normal cases. The not-normal case is incomplete
description, which does not happen here.
The pinctrls I guess as well in DTSI, because you do not customize the
pins in the DTS. IOW, if the pinctrl nodes are coming from shared
pinctrl.DTSI, then pinctrl-0/names stay in DTSI as well.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-15 8:13 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:13 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
I don't understand what it has to do with the bindings.
>
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
Neither here. Clock names are not related to defines.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> drivers/clk/samsung/clk-gs101.c | 167 ++++++++++++-----------
> include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
I miss the point why bindings must be changed with driver.
Really, guys, we are milling the first GS101 patches for entire cycle.
Almost 3 months. The moment I merge bindings you tell me they are wrong.
Few days after merging them.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-15 8:13 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 8:13 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 14/12/2023 11:52, Tudor Ambarus wrote:
> The gs101 clock names are derived from the clock register names under
> some certain rules. In particular, for the gate clocks the following is
> documented and expected in the gs101 clock driver:
>
> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>
> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
I don't understand what it has to do with the bindings.
>
> The CMU TOP gate clock names missed to include the required "CMU"
> differentiator which will cause name collisions with the gate clock names
> of other clock units. Fix the TOP gate clock names and include "CMU" in
> their name.
Neither here. Clock names are not related to defines.
>
> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> drivers/clk/samsung/clk-gs101.c | 167 ++++++++++++-----------
> include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
I miss the point why bindings must be changed with driver.
Really, guys, we are milling the first GS101 patches for entire cycle.
Almost 3 months. The moment I merge bindings you tell me they are wrong.
Few days after merging them.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-15 8:13 ` Krzysztof Kozlowski
@ 2023-12-15 10:23 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-15 10:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, peter.griffin, robh+dt,
krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi, Krzysztof,
On 12/15/23 08:13, Krzysztof Kozlowski wrote:
> On 14/12/2023 11:52, Tudor Ambarus wrote:
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
> I don't understand what it has to do with the bindings.
>
>>
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
>
> Neither here. Clock names are not related to defines.
>
When saying "clock names" I meant the clock symbolic names that are
defined in the bindings, the _id passed in GATE(_id, ) if you want.
>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> drivers/clk/samsung/clk-gs101.c | 167 ++++++++++++-----------
>> include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
>
> I miss the point why bindings must be changed with driver.
The clock symbolic names that are defined in the bindings file are used
as IDs in the clock driver. Having the changes split per file will
result in compilation errors breaking bisect.
>
> Really, guys, we are milling the first GS101 patches for entire cycle.
> Almost 3 months. The moment I merge bindings you tell me they are wrong.
> Few days after merging them.
I apologize. It happens when we work in parallel. The clock symbolic
names were mangled just in v6. It was considered that the clock names
used in the datasheet are too long and the dt becomes unreadable. I just
recently updated the peric0 clock symbolic names according to the clock
symbolic name mangling strategy, that's why we spot the inconsistency
and the symbolic name collision so late.
Cheers,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-15 10:23 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-15 10:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, peter.griffin, robh+dt,
krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi, Krzysztof,
On 12/15/23 08:13, Krzysztof Kozlowski wrote:
> On 14/12/2023 11:52, Tudor Ambarus wrote:
>> The gs101 clock names are derived from the clock register names under
>> some certain rules. In particular, for the gate clocks the following is
>> documented and expected in the gs101 clock driver:
>>
>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>
>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>
> I don't understand what it has to do with the bindings.
>
>>
>> The CMU TOP gate clock names missed to include the required "CMU"
>> differentiator which will cause name collisions with the gate clock names
>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>> their name.
>
> Neither here. Clock names are not related to defines.
>
When saying "clock names" I meant the clock symbolic names that are
defined in the bindings, the _id passed in GATE(_id, ) if you want.
>>
>> Fixes: 0a910f160638 ("dt-bindings: clock: Add Google gs101 clock management unit bindings")
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> drivers/clk/samsung/clk-gs101.c | 167 ++++++++++++-----------
>> include/dt-bindings/clock/google,gs101.h | 144 +++++++++----------
>
> I miss the point why bindings must be changed with driver.
The clock symbolic names that are defined in the bindings file are used
as IDs in the clock driver. Having the changes split per file will
result in compilation errors breaking bisect.
>
> Really, guys, we are milling the first GS101 patches for entire cycle.
> Almost 3 months. The moment I merge bindings you tell me they are wrong.
> Few days after merging them.
I apologize. It happens when we work in parallel. The clock symbolic
names were mangled just in v6. It was considered that the clock names
used in the datasheet are too long and the dt becomes unreadable. I just
recently updated the peric0 clock symbolic names according to the clock
symbolic name mangling strategy, that's why we spot the inconsistency
and the symbolic name collision so late.
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-15 10:23 ` Tudor Ambarus
@ 2023-12-15 19:24 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 19:24 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 15/12/2023 11:23, Tudor Ambarus wrote:
> Hi, Krzysztof,
>
> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>> The gs101 clock names are derived from the clock register names under
>>> some certain rules. In particular, for the gate clocks the following is
>>> documented and expected in the gs101 clock driver:
>>>
>>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>
>>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>
>> I don't understand what it has to do with the bindings.
>>
>>>
>>> The CMU TOP gate clock names missed to include the required "CMU"
>>> differentiator which will cause name collisions with the gate clock names
>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>> their name.
>>
>> Neither here. Clock names are not related to defines.
>>
>
> When saying "clock names" I meant the clock symbolic names that are
> defined in the bindings, the _id passed in GATE(_id, ) if you want.
Please re-phrase the commit message to say that you need to rename the
defines in the bindings headers. If you change anything else, like clock
names, then it should be separate patch.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-15 19:24 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 19:24 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 15/12/2023 11:23, Tudor Ambarus wrote:
> Hi, Krzysztof,
>
> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>> The gs101 clock names are derived from the clock register names under
>>> some certain rules. In particular, for the gate clocks the following is
>>> documented and expected in the gs101 clock driver:
>>>
>>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>
>>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>
>> I don't understand what it has to do with the bindings.
>>
>>>
>>> The CMU TOP gate clock names missed to include the required "CMU"
>>> differentiator which will cause name collisions with the gate clock names
>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>> their name.
>>
>> Neither here. Clock names are not related to defines.
>>
>
> When saying "clock names" I meant the clock symbolic names that are
> defined in the bindings, the _id passed in GATE(_id, ) if you want.
Please re-phrase the commit message to say that you need to rename the
defines in the bindings headers. If you change anything else, like clock
names, then it should be separate patch.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-15 19:24 ` Krzysztof Kozlowski
@ 2023-12-15 19:25 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 19:25 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 15/12/2023 20:24, Krzysztof Kozlowski wrote:
> On 15/12/2023 11:23, Tudor Ambarus wrote:
>> Hi, Krzysztof,
>>
>> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>>> The gs101 clock names are derived from the clock register names under
>>>> some certain rules. In particular, for the gate clocks the following is
>>>> documented and expected in the gs101 clock driver:
>>>>
>>>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>
>>>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>>
>>> I don't understand what it has to do with the bindings.
>>>
>>>>
>>>> The CMU TOP gate clock names missed to include the required "CMU"
>>>> differentiator which will cause name collisions with the gate clock names
>>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>>> their name.
>>>
>>> Neither here. Clock names are not related to defines.
>>>
>>
>> When saying "clock names" I meant the clock symbolic names that are
>> defined in the bindings, the _id passed in GATE(_id, ) if you want.
>
> Please re-phrase the commit message to say that you need to rename the
> defines in the bindings headers. If you change anything else, like clock
> names, then it should be separate patch.
I forgot:
You can also respin this patch separately, as soon as possible, because
it has to go this cycle.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-15 19:25 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-15 19:25 UTC (permalink / raw)
To: Tudor Ambarus, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
mturquette, sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh,
jirislaby, catalin.marinas, will, s.nawrocki, tomasz.figa,
cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 15/12/2023 20:24, Krzysztof Kozlowski wrote:
> On 15/12/2023 11:23, Tudor Ambarus wrote:
>> Hi, Krzysztof,
>>
>> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>>> The gs101 clock names are derived from the clock register names under
>>>> some certain rules. In particular, for the gate clocks the following is
>>>> documented and expected in the gs101 clock driver:
>>>>
>>>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>
>>>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>>
>>> I don't understand what it has to do with the bindings.
>>>
>>>>
>>>> The CMU TOP gate clock names missed to include the required "CMU"
>>>> differentiator which will cause name collisions with the gate clock names
>>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>>> their name.
>>>
>>> Neither here. Clock names are not related to defines.
>>>
>>
>> When saying "clock names" I meant the clock symbolic names that are
>> defined in the bindings, the _id passed in GATE(_id, ) if you want.
>
> Please re-phrase the commit message to say that you need to rename the
> defines in the bindings headers. If you change anything else, like clock
> names, then it should be separate patch.
I forgot:
You can also respin this patch separately, as soon as possible, because
it has to go this cycle.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-15 19:42 ` Rob Herring
-1 siblings, 0 replies; 122+ messages in thread
From: Rob Herring @ 2023-12-15 19:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: will, jirislaby, alim.akhtar, arnd, peter.griffin,
linux-arm-kernel, devicetree, s.nawrocki, andi.shyti,
linux-serial, saravanak, sboyd, cw00.choi, linux-i2c,
andre.draszik, robh+dt, willmcvicker, linux-clk, linux-kernel,
tomasz.figa, conor+dt, catalin.marinas, linux-samsung-soc,
gregkh, krzysztof.kozlowski+dt, mturquette, semen.protsenko
On Thu, 14 Dec 2023 10:52:33 +0000, Tudor Ambarus wrote:
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible
@ 2023-12-15 19:42 ` Rob Herring
0 siblings, 0 replies; 122+ messages in thread
From: Rob Herring @ 2023-12-15 19:42 UTC (permalink / raw)
To: Tudor Ambarus
Cc: will, jirislaby, alim.akhtar, arnd, peter.griffin,
linux-arm-kernel, devicetree, s.nawrocki, andi.shyti,
linux-serial, saravanak, sboyd, cw00.choi, linux-i2c,
andre.draszik, robh+dt, willmcvicker, linux-clk, linux-kernel,
tomasz.figa, conor+dt, catalin.marinas, linux-samsung-soc,
gregkh, krzysztof.kozlowski+dt, mturquette, semen.protsenko
On Thu, 14 Dec 2023 10:52:33 +0000, Tudor Ambarus wrote:
> Add google,gs101-hsi2c dedicated compatible for representing
> I2C of Google GS101 SoC.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
2023-12-15 19:25 ` Krzysztof Kozlowski
@ 2023-12-18 6:50 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-18 6:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, peter.griffin, robh+dt,
krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/15/23 19:25, Krzysztof Kozlowski wrote:
> On 15/12/2023 20:24, Krzysztof Kozlowski wrote:
>> On 15/12/2023 11:23, Tudor Ambarus wrote:
>>> Hi, Krzysztof,
>>>
>>> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>>>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>>>> The gs101 clock names are derived from the clock register names under
>>>>> some certain rules. In particular, for the gate clocks the following is
>>>>> documented and expected in the gs101 clock driver:
>>>>>
>>>>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>>
>>>>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>>>
>>>> I don't understand what it has to do with the bindings.
>>>>
>>>>>
>>>>> The CMU TOP gate clock names missed to include the required "CMU"
>>>>> differentiator which will cause name collisions with the gate clock names
>>>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>>>> their name.
>>>>
>>>> Neither here. Clock names are not related to defines.
>>>>
>>>
>>> When saying "clock names" I meant the clock symbolic names that are
>>> defined in the bindings, the _id passed in GATE(_id, ) if you want.
>>
>> Please re-phrase the commit message to say that you need to rename the
>> defines in the bindings headers. If you change anything else, like clock
>> names, then it should be separate patch.
>
> I forgot:
> You can also respin this patch separately, as soon as possible, because
> it has to go this cycle.
>
Sent here:
https://lore.kernel.org/linux-arm-kernel/20231218064333.479885-1-tudor.ambarus@linaro.org/
Thanks,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names
@ 2023-12-18 6:50 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-18 6:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, peter.griffin, robh+dt,
krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt, andi.shyti,
alim.akhtar, gregkh, jirislaby, catalin.marinas, will,
s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko
Cc: andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On 12/15/23 19:25, Krzysztof Kozlowski wrote:
> On 15/12/2023 20:24, Krzysztof Kozlowski wrote:
>> On 15/12/2023 11:23, Tudor Ambarus wrote:
>>> Hi, Krzysztof,
>>>
>>> On 12/15/23 08:13, Krzysztof Kozlowski wrote:
>>>> On 14/12/2023 11:52, Tudor Ambarus wrote:
>>>>> The gs101 clock names are derived from the clock register names under
>>>>> some certain rules. In particular, for the gate clocks the following is
>>>>> documented and expected in the gs101 clock driver:
>>>>>
>>>>> Replace CLK_CON_GAT_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>> Replace CLK_CON_GAT_GATE_CLKCMU with CLK_GOUT_CMU and gout_cmu
>>>>>
>>>>> For gates remove _UID _BLK _IPCLKPORT and _RSTNSYNC
>>>>
>>>> I don't understand what it has to do with the bindings.
>>>>
>>>>>
>>>>> The CMU TOP gate clock names missed to include the required "CMU"
>>>>> differentiator which will cause name collisions with the gate clock names
>>>>> of other clock units. Fix the TOP gate clock names and include "CMU" in
>>>>> their name.
>>>>
>>>> Neither here. Clock names are not related to defines.
>>>>
>>>
>>> When saying "clock names" I meant the clock symbolic names that are
>>> defined in the bindings, the _id passed in GATE(_id, ) if you want.
>>
>> Please re-phrase the commit message to say that you need to rename the
>> defines in the bindings headers. If you change anything else, like clock
>> names, then it should be separate patch.
>
> I forgot:
> You can also respin this patch separately, as soon as possible, because
> it has to go this cycle.
>
Sent here:
https://lore.kernel.org/linux-arm-kernel/20231218064333.479885-1-tudor.ambarus@linaro.org/
Thanks,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-14 16:43 ` Sam Protsenko
@ 2023-12-19 16:47 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-19 16:47 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi, Sam!
On 12/14/23 16:43, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>>
>>
>> On 12/14/23 16:09, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/14/23 15:37, Sam Protsenko wrote:
>>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>
>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>>>> which then makes the system hang. To prevent this, mark
>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>>>> accordingly when tested.
>>>>>>
>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>>> ---
>>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>>> 21, 0, 0),
>>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>>>
>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>>>> usually should be avoided. Is it possible that the system freezes
>>>>> because some other clock (which depends on peric0_ip) gets disabled as
>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>>>> is not implemented yet in the clock driver? Just looks weird to me
>>>>> that the system hangs because of CMU IP clock disablement. It's
>>>>> usually something much more specific.
>>>>
>>>> The system hang happened when I tested USI8 in I2C configuration with an
>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>>>
>>>
>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>>
>> yes.
I checked again all the clocks. I implemented all but one, the one
defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
don't have any reference on how it should be defined so I won't touch it
yet. But I have some good news too, see below.
>
> Ok. Are there any other CMUs (perhaps not implemented yet) which
> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> clocks derived from it? If so, is there a chance some particular leaf
> clock in those CMUs actually renders the system frozen when disabled
> as a consequence of disabling PERIC0_IP, and would explain better why
> the freeze happens?
>
> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> because as you said you implemented all clocks in this CMU and neither
> of those looks like a critical one. But I'd advice to add a TODO
> comment saying it's probably a temporary solution before actual leaf
> clock which leads to freeze is identified (which probably resides in
> some other not implemented yet CMU).
>
>>
>>> is a chance some other leaf clock (which is not implemented yet in
>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
>>> might actually lead to that hang you observe. Usually it's some
>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
>>> and the corresponding comments I left there, maybe it'll give you more
>>> particular idea about what to look for. Yes, making the whole CMU
>>> always running without understanding why (i.e. because of which
>>> particular leaf clock) might not be the best way of handling this
>>
>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
>
> That's not a root cause here. And I think PERIC0_IP is neither.
>
you were right!
>>
>>> issue. I might be mistaken, but at least please check if you
>>> implemented all clocks for PERIC0 first and if making some meaningful
>>> leaf clock critical makes more sense.
>>>
I determined which leaf clocks shall be marked as critical. I enabled
the debugfs clock write access. Then I made sure that the parents of the
PERIC0 CMU have at least one user so that they don't get disabled after
an enable-disable sequence on a leaf clock. The I took all the PERIC0
gate clocks and enabled and disabled them one by one. Whichever hang the
system when the clock was disabled was marked as critical. The list of
critical leaf clocks is as following:
"gout_peric0_peric0_cmu_peric0_pclk",
"gout_peric0_lhm_axi_p_peric0_i_clk",
"gout_peric0_peric0_top1_ipclk_0",
"gout_peric0_peric0_top1_pclk_0".
I'll update v2 with this instead. Thanks for the help, Sam!
Cheers,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-19 16:47 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-19 16:47 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi, Sam!
On 12/14/23 16:43, Sam Protsenko wrote:
> On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>>
>>
>> On 12/14/23 16:09, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/14/23 15:37, Sam Protsenko wrote:
>>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>
>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>>>> which then makes the system hang. To prevent this, mark
>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>>>> accordingly when tested.
>>>>>>
>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>>> ---
>>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>>> 21, 0, 0),
>>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>>>
>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>>>> usually should be avoided. Is it possible that the system freezes
>>>>> because some other clock (which depends on peric0_ip) gets disabled as
>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>>>> is not implemented yet in the clock driver? Just looks weird to me
>>>>> that the system hangs because of CMU IP clock disablement. It's
>>>>> usually something much more specific.
>>>>
>>>> The system hang happened when I tested USI8 in I2C configuration with an
>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>>>
>>>
>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>>
>> yes.
I checked again all the clocks. I implemented all but one, the one
defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
don't have any reference on how it should be defined so I won't touch it
yet. But I have some good news too, see below.
>
> Ok. Are there any other CMUs (perhaps not implemented yet) which
> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> clocks derived from it? If so, is there a chance some particular leaf
> clock in those CMUs actually renders the system frozen when disabled
> as a consequence of disabling PERIC0_IP, and would explain better why
> the freeze happens?
>
> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> because as you said you implemented all clocks in this CMU and neither
> of those looks like a critical one. But I'd advice to add a TODO
> comment saying it's probably a temporary solution before actual leaf
> clock which leads to freeze is identified (which probably resides in
> some other not implemented yet CMU).
>
>>
>>> is a chance some other leaf clock (which is not implemented yet in
>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
>>> might actually lead to that hang you observe. Usually it's some
>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
>>> and the corresponding comments I left there, maybe it'll give you more
>>> particular idea about what to look for. Yes, making the whole CMU
>>> always running without understanding why (i.e. because of which
>>> particular leaf clock) might not be the best way of handling this
>>
>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
>
> That's not a root cause here. And I think PERIC0_IP is neither.
>
you were right!
>>
>>> issue. I might be mistaken, but at least please check if you
>>> implemented all clocks for PERIC0 first and if making some meaningful
>>> leaf clock critical makes more sense.
>>>
I determined which leaf clocks shall be marked as critical. I enabled
the debugfs clock write access. Then I made sure that the parents of the
PERIC0 CMU have at least one user so that they don't get disabled after
an enable-disable sequence on a leaf clock. The I took all the PERIC0
gate clocks and enabled and disabled them one by one. Whichever hang the
system when the clock was disabled was marked as critical. The list of
critical leaf clocks is as following:
"gout_peric0_peric0_cmu_peric0_pclk",
"gout_peric0_lhm_axi_p_peric0_i_clk",
"gout_peric0_peric0_top1_ipclk_0",
"gout_peric0_peric0_top1_pclk_0".
I'll update v2 with this instead. Thanks for the help, Sam!
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-19 16:47 ` Tudor Ambarus
@ 2023-12-19 17:31 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-19 17:31 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Tue, Dec 19, 2023 at 10:47 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Hi, Sam!
>
> On 12/14/23 16:43, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >>
> >>
> >> On 12/14/23 16:09, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/14/23 15:37, Sam Protsenko wrote:
> >>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>>>
> >>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>>>> which then makes the system hang. To prevent this, mark
> >>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>>>> accordingly when tested.
> >>>>>>
> >>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >>>>>> ---
> >>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>>> 21, 0, 0),
> >>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>>>
> >>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>>>> usually should be avoided. Is it possible that the system freezes
> >>>>> because some other clock (which depends on peric0_ip) gets disabled as
> >>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>>>> is not implemented yet in the clock driver? Just looks weird to me
> >>>>> that the system hangs because of CMU IP clock disablement. It's
> >>>>> usually something much more specific.
> >>>>
> >>>> The system hang happened when I tested USI8 in I2C configuration with an
> >>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >>>> disablement which makes the system hang. Either marking the CMU_TOP gate
> >>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>>>
> >>>
> >>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
> >>
> >> yes.
>
> I checked again all the clocks. I implemented all but one, the one
> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
> don't have any reference on how it should be defined so I won't touch it
> yet. But I have some good news too, see below.
>
> >
> > Ok. Are there any other CMUs (perhaps not implemented yet) which
> > consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> > clocks derived from it? If so, is there a chance some particular leaf
> > clock in those CMUs actually renders the system frozen when disabled
> > as a consequence of disabling PERIC0_IP, and would explain better why
> > the freeze happens?
> >
> > For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> > because as you said you implemented all clocks in this CMU and neither
> > of those looks like a critical one. But I'd advice to add a TODO
> > comment saying it's probably a temporary solution before actual leaf
> > clock which leads to freeze is identified (which probably resides in
> > some other not implemented yet CMU).
> >
> >>
> >>> is a chance some other leaf clock (which is not implemented yet in
> >>> your driver) gets disabled as a result of PERIC0_IP disablement, which
> >>> might actually lead to that hang you observe. Usually it's some
> >>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> >>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> >>> and the corresponding comments I left there, maybe it'll give you more
> >>> particular idea about what to look for. Yes, making the whole CMU
> >>> always running without understanding why (i.e. because of which
> >>> particular leaf clock) might not be the best way of handling this
> >>
> >> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> >
> > That's not a root cause here. And I think PERIC0_IP is neither.
> >
>
> you were right!
> >>
> >>> issue. I might be mistaken, but at least please check if you
> >>> implemented all clocks for PERIC0 first and if making some meaningful
> >>> leaf clock critical makes more sense.
> >>>
>
> I determined which leaf clocks shall be marked as critical. I enabled
> the debugfs clock write access. Then I made sure that the parents of the
> PERIC0 CMU have at least one user so that they don't get disabled after
> an enable-disable sequence on a leaf clock. The I took all the PERIC0
> gate clocks and enabled and disabled them one by one. Whichever hang the
> system when the clock was disabled was marked as critical. The list of
> critical leaf clocks is as following:
>
Nice! I used somehow similar procedure for clk-exynos850, doing
basically the same thing, but in core clock driver code.
> "gout_peric0_peric0_cmu_peric0_pclk",
> "gout_peric0_lhm_axi_p_peric0_i_clk",
> "gout_peric0_peric0_top1_ipclk_0",
> "gout_peric0_peric0_top1_pclk_0".
>
> I'll update v2 with this instead. Thanks for the help, Sam!
Glad you weren't discouraged by my meticulousness :) In clk-exynos850
I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
clocks usually can be used to disable the bus clock for corresponding
CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
access the registers from that CMU block, as its register interface is
not clocked anymore. Guess I saw something similar in Exynos5433 or
Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
-- don't really remember. For AXI clock it also seems logical to keep
it running (AXI bus might be used for GIC and memory). But again,
maybe CLK_IGNORE_UNUSED flag would be more appropriate that
CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
exactly they do. Is TOP1 some other CMU or block name, and is there
any further users for those clocks?
Anyways, if you are working on v2, please consider doing next two
things while at it:
1. For each critical clock: add corresponding comment explaining why
it's marked so
2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
appropriate; both have their use in different cases
Btw, if you check other Exynos clk drivers, there is a lot of examples
for flags like those.
> Cheers,
> ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-19 17:31 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-19 17:31 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Tue, Dec 19, 2023 at 10:47 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Hi, Sam!
>
> On 12/14/23 16:43, Sam Protsenko wrote:
> > On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >>
> >>
> >> On 12/14/23 16:09, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/14/23 15:37, Sam Protsenko wrote:
> >>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>>>
> >>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>>>> which then makes the system hang. To prevent this, mark
> >>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>>>> accordingly when tested.
> >>>>>>
> >>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >>>>>> ---
> >>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>>> 21, 0, 0),
> >>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>>>
> >>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>>>> usually should be avoided. Is it possible that the system freezes
> >>>>> because some other clock (which depends on peric0_ip) gets disabled as
> >>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>>>> is not implemented yet in the clock driver? Just looks weird to me
> >>>>> that the system hangs because of CMU IP clock disablement. It's
> >>>>> usually something much more specific.
> >>>>
> >>>> The system hang happened when I tested USI8 in I2C configuration with an
> >>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >>>> disablement which makes the system hang. Either marking the CMU_TOP gate
> >>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>>>
> >>>
> >>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
> >>
> >> yes.
>
> I checked again all the clocks. I implemented all but one, the one
> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
> don't have any reference on how it should be defined so I won't touch it
> yet. But I have some good news too, see below.
>
> >
> > Ok. Are there any other CMUs (perhaps not implemented yet) which
> > consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> > clocks derived from it? If so, is there a chance some particular leaf
> > clock in those CMUs actually renders the system frozen when disabled
> > as a consequence of disabling PERIC0_IP, and would explain better why
> > the freeze happens?
> >
> > For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> > because as you said you implemented all clocks in this CMU and neither
> > of those looks like a critical one. But I'd advice to add a TODO
> > comment saying it's probably a temporary solution before actual leaf
> > clock which leads to freeze is identified (which probably resides in
> > some other not implemented yet CMU).
> >
> >>
> >>> is a chance some other leaf clock (which is not implemented yet in
> >>> your driver) gets disabled as a result of PERIC0_IP disablement, which
> >>> might actually lead to that hang you observe. Usually it's some
> >>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> >>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> >>> and the corresponding comments I left there, maybe it'll give you more
> >>> particular idea about what to look for. Yes, making the whole CMU
> >>> always running without understanding why (i.e. because of which
> >>> particular leaf clock) might not be the best way of handling this
> >>
> >> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> >
> > That's not a root cause here. And I think PERIC0_IP is neither.
> >
>
> you were right!
> >>
> >>> issue. I might be mistaken, but at least please check if you
> >>> implemented all clocks for PERIC0 first and if making some meaningful
> >>> leaf clock critical makes more sense.
> >>>
>
> I determined which leaf clocks shall be marked as critical. I enabled
> the debugfs clock write access. Then I made sure that the parents of the
> PERIC0 CMU have at least one user so that they don't get disabled after
> an enable-disable sequence on a leaf clock. The I took all the PERIC0
> gate clocks and enabled and disabled them one by one. Whichever hang the
> system when the clock was disabled was marked as critical. The list of
> critical leaf clocks is as following:
>
Nice! I used somehow similar procedure for clk-exynos850, doing
basically the same thing, but in core clock driver code.
> "gout_peric0_peric0_cmu_peric0_pclk",
> "gout_peric0_lhm_axi_p_peric0_i_clk",
> "gout_peric0_peric0_top1_ipclk_0",
> "gout_peric0_peric0_top1_pclk_0".
>
> I'll update v2 with this instead. Thanks for the help, Sam!
Glad you weren't discouraged by my meticulousness :) In clk-exynos850
I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
clocks usually can be used to disable the bus clock for corresponding
CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
access the registers from that CMU block, as its register interface is
not clocked anymore. Guess I saw something similar in Exynos5433 or
Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
-- don't really remember. For AXI clock it also seems logical to keep
it running (AXI bus might be used for GIC and memory). But again,
maybe CLK_IGNORE_UNUSED flag would be more appropriate that
CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
exactly they do. Is TOP1 some other CMU or block name, and is there
any further users for those clocks?
Anyways, if you are working on v2, please consider doing next two
things while at it:
1. For each critical clock: add corresponding comment explaining why
it's marked so
2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
appropriate; both have their use in different cases
Btw, if you check other Exynos clk drivers, there is a lot of examples
for flags like those.
> Cheers,
> ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-19 17:31 ` Sam Protsenko
@ 2023-12-20 14:22 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-20 14:22 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi, Sam!
On 12/19/23 17:31, Sam Protsenko wrote:
> On Tue, Dec 19, 2023 at 10:47 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Hi, Sam!
>>
>> On 12/14/23 16:43, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/14/23 16:09, Sam Protsenko wrote:
>>>>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/14/23 15:37, Sam Protsenko wrote:
>>>>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>>>
>>>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>>>>>> which then makes the system hang. To prevent this, mark
>>>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>>>>>> accordingly when tested.
>>>>>>>>
>>>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>>>>> ---
>>>>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>>>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>>>>> 21, 0, 0),
>>>>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>>>>>
>>>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>>>>>> usually should be avoided. Is it possible that the system freezes
>>>>>>> because some other clock (which depends on peric0_ip) gets disabled as
>>>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>>>>>> is not implemented yet in the clock driver? Just looks weird to me
>>>>>>> that the system hangs because of CMU IP clock disablement. It's
>>>>>>> usually something much more specific.
>>>>>>
>>>>>> The system hang happened when I tested USI8 in I2C configuration with an
>>>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>>>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>>>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>>>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
>>>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>>>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>>>>>
>>>>>
>>>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>>>>
>>>> yes.
>>
>> I checked again all the clocks. I implemented all but one, the one
>> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
>> don't have any reference on how it should be defined so I won't touch it
>> yet. But I have some good news too, see below.
>>
>>>
>>> Ok. Are there any other CMUs (perhaps not implemented yet) which
>>> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
>>> clocks derived from it? If so, is there a chance some particular leaf
>>> clock in those CMUs actually renders the system frozen when disabled
>>> as a consequence of disabling PERIC0_IP, and would explain better why
>>> the freeze happens?
>>>
>>> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
>>> because as you said you implemented all clocks in this CMU and neither
>>> of those looks like a critical one. But I'd advice to add a TODO
>>> comment saying it's probably a temporary solution before actual leaf
>>> clock which leads to freeze is identified (which probably resides in
>>> some other not implemented yet CMU).
>>>
>>>>
>>>>> is a chance some other leaf clock (which is not implemented yet in
>>>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
>>>>> might actually lead to that hang you observe. Usually it's some
>>>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
>>>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
>>>>> and the corresponding comments I left there, maybe it'll give you more
>>>>> particular idea about what to look for. Yes, making the whole CMU
>>>>> always running without understanding why (i.e. because of which
>>>>> particular leaf clock) might not be the best way of handling this
>>>>
>>>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
>>>
>>> That's not a root cause here. And I think PERIC0_IP is neither.
>>>
>>
>> you were right!
>>>>
>>>>> issue. I might be mistaken, but at least please check if you
>>>>> implemented all clocks for PERIC0 first and if making some meaningful
>>>>> leaf clock critical makes more sense.
>>>>>
>>
>> I determined which leaf clocks shall be marked as critical. I enabled
>> the debugfs clock write access. Then I made sure that the parents of the
>> PERIC0 CMU have at least one user so that they don't get disabled after
>> an enable-disable sequence on a leaf clock. The I took all the PERIC0
>> gate clocks and enabled and disabled them one by one. Whichever hang the
>> system when the clock was disabled was marked as critical. The list of
>> critical leaf clocks is as following:
>>
>
> Nice! I used somehow similar procedure for clk-exynos850, doing
> basically the same thing, but in core clock driver code.
>
>> "gout_peric0_peric0_cmu_peric0_pclk",
>> "gout_peric0_lhm_axi_p_peric0_i_clk",
>> "gout_peric0_peric0_top1_ipclk_0",
>> "gout_peric0_peric0_top1_pclk_0".
>>
>> I'll update v2 with this instead. Thanks for the help, Sam!
>
> Glad you weren't discouraged by my meticulousness :) In clk-exynos850
> I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
> case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
> clocks usually can be used to disable the bus clock for corresponding
> CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
> access the registers from that CMU block, as its register interface is
> not clocked anymore. Guess I saw something similar in Exynos5433 or
> Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
> -- don't really remember. For AXI clock it also seems logical to keep
> it running (AXI bus might be used for GIC and memory). But again,
> maybe CLK_IGNORE_UNUSED flag would be more appropriate that
> CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
> exactly they do. Is TOP1 some other CMU or block name, and is there
> any further users for those clocks?
>
> Anyways, if you are working on v2, please consider doing next two
> things while at it:
>
> 1. For each critical clock: add corresponding comment explaining why
> it's marked so
Will do.
> 2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
> appropriate; both have their use in different cases
>
> Btw, if you check other Exynos clk drivers, there is a lot of examples
> for flags like those.
>
Thanks for the feedback, it's educative.
I played a little with the clk debugfs and I think all should be marked
as critical. What I did was to make sure that their parents are enabled
already and then I enabled and disabled each. Each time I disabled one
of them the system hung. Thus in case they will be used, if one disable
them on an error path, it will hang the system. We can't disable them at
suspend either. Thus I propose to keep them as critical.
Thanks!
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-20 14:22 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-20 14:22 UTC (permalink / raw)
To: Sam Protsenko
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi, Sam!
On 12/19/23 17:31, Sam Protsenko wrote:
> On Tue, Dec 19, 2023 at 10:47 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>
>> Hi, Sam!
>>
>> On 12/14/23 16:43, Sam Protsenko wrote:
>>> On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/14/23 16:09, Sam Protsenko wrote:
>>>>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/14/23 15:37, Sam Protsenko wrote:
>>>>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>>>>>>>>
>>>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
>>>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
>>>>>>>> which then makes the system hang. To prevent this, mark
>>>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
>>>>>>>> accordingly when tested.
>>>>>>>>
>>>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>>>>> ---
>>>>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
>>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
>>>>>>>> index 3d194520b05e..08d80fca9cd6 100644
>>>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
>>>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
>>>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
>>>>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
>>>>>>>> 21, 0, 0),
>>>>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
>>>>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
>>>>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
>>>>>>>
>>>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
>>>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
>>>>>>> usually should be avoided. Is it possible that the system freezes
>>>>>>> because some other clock (which depends on peric0_ip) gets disabled as
>>>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
>>>>>>> is not implemented yet in the clock driver? Just looks weird to me
>>>>>>> that the system hangs because of CMU IP clock disablement. It's
>>>>>>> usually something much more specific.
>>>>>>
>>>>>> The system hang happened when I tested USI8 in I2C configuration with an
>>>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
>>>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
>>>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
>>>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
>>>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
>>>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
>>>>>>
>>>>>
>>>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
>>>>
>>>> yes.
>>
>> I checked again all the clocks. I implemented all but one, the one
>> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
>> don't have any reference on how it should be defined so I won't touch it
>> yet. But I have some good news too, see below.
>>
>>>
>>> Ok. Are there any other CMUs (perhaps not implemented yet) which
>>> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
>>> clocks derived from it? If so, is there a chance some particular leaf
>>> clock in those CMUs actually renders the system frozen when disabled
>>> as a consequence of disabling PERIC0_IP, and would explain better why
>>> the freeze happens?
>>>
>>> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
>>> because as you said you implemented all clocks in this CMU and neither
>>> of those looks like a critical one. But I'd advice to add a TODO
>>> comment saying it's probably a temporary solution before actual leaf
>>> clock which leads to freeze is identified (which probably resides in
>>> some other not implemented yet CMU).
>>>
>>>>
>>>>> is a chance some other leaf clock (which is not implemented yet in
>>>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
>>>>> might actually lead to that hang you observe. Usually it's some
>>>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
>>>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
>>>>> and the corresponding comments I left there, maybe it'll give you more
>>>>> particular idea about what to look for. Yes, making the whole CMU
>>>>> always running without understanding why (i.e. because of which
>>>>> particular leaf clock) might not be the best way of handling this
>>>>
>>>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
>>>
>>> That's not a root cause here. And I think PERIC0_IP is neither.
>>>
>>
>> you were right!
>>>>
>>>>> issue. I might be mistaken, but at least please check if you
>>>>> implemented all clocks for PERIC0 first and if making some meaningful
>>>>> leaf clock critical makes more sense.
>>>>>
>>
>> I determined which leaf clocks shall be marked as critical. I enabled
>> the debugfs clock write access. Then I made sure that the parents of the
>> PERIC0 CMU have at least one user so that they don't get disabled after
>> an enable-disable sequence on a leaf clock. The I took all the PERIC0
>> gate clocks and enabled and disabled them one by one. Whichever hang the
>> system when the clock was disabled was marked as critical. The list of
>> critical leaf clocks is as following:
>>
>
> Nice! I used somehow similar procedure for clk-exynos850, doing
> basically the same thing, but in core clock driver code.
>
>> "gout_peric0_peric0_cmu_peric0_pclk",
>> "gout_peric0_lhm_axi_p_peric0_i_clk",
>> "gout_peric0_peric0_top1_ipclk_0",
>> "gout_peric0_peric0_top1_pclk_0".
>>
>> I'll update v2 with this instead. Thanks for the help, Sam!
>
> Glad you weren't discouraged by my meticulousness :) In clk-exynos850
> I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
> case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
> clocks usually can be used to disable the bus clock for corresponding
> CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
> access the registers from that CMU block, as its register interface is
> not clocked anymore. Guess I saw something similar in Exynos5433 or
> Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
> -- don't really remember. For AXI clock it also seems logical to keep
> it running (AXI bus might be used for GIC and memory). But again,
> maybe CLK_IGNORE_UNUSED flag would be more appropriate that
> CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
> exactly they do. Is TOP1 some other CMU or block name, and is there
> any further users for those clocks?
>
> Anyways, if you are working on v2, please consider doing next two
> things while at it:
>
> 1. For each critical clock: add corresponding comment explaining why
> it's marked so
Will do.
> 2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
> appropriate; both have their use in different cases
>
> Btw, if you check other Exynos clk drivers, there is a lot of examples
> for flags like those.
>
Thanks for the feedback, it's educative.
I played a little with the clk debugfs and I think all should be marked
as critical. What I did was to make sure that their parents are enabled
already and then I enabled and disabled each. Each time I disabled one
of them the system hung. Thus in case they will be used, if one disable
them on an error path, it will hang the system. We can't disable them at
suspend either. Thus I propose to keep them as critical.
Thanks!
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-14 10:52 ` Tudor Ambarus
@ 2023-12-20 15:07 ` Rob Herring
-1 siblings, 0 replies; 122+ messages in thread
From: Rob Herring @ 2023-12-20 15:07 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, krzysztof.kozlowski+dt, mturquette, sboyd,
conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> clock management unit.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
> 2 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> index 3eebc03a309b..ba54c13c55bc 100644
> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -30,14 +30,15 @@ properties:
> - google,gs101-cmu-top
> - google,gs101-cmu-apm
> - google,gs101-cmu-misc
> + - google,gs101-cmu-peric0
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> clock-names:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> "#clock-cells":
> const: 1
> @@ -88,6 +89,26 @@ allOf:
> - const: dout_cmu_misc_bus
> - const: dout_cmu_misc_sss
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: google,gs101-cmu-peric0
> +
> + then:
> + properties:
> + clocks:
> + items:
> + - description: External reference clock (24.576 MHz)
> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> +
> + clock-names:
> + items:
> + - const: oscclk
> + - const: dout_cmu_peric0_bus
> + - const: dout_cmu_peric0_ip
'bus' and 'ip' are sufficient because naming is local to the module. The
same is true on 'dout_cmu_misc_bus'. As that has not made a release,
please fix all of them.
Rob
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-20 15:07 ` Rob Herring
0 siblings, 0 replies; 122+ messages in thread
From: Rob Herring @ 2023-12-20 15:07 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, krzysztof.kozlowski+dt, mturquette, sboyd,
conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> clock management unit.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> ---
> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
> 2 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> index 3eebc03a309b..ba54c13c55bc 100644
> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> @@ -30,14 +30,15 @@ properties:
> - google,gs101-cmu-top
> - google,gs101-cmu-apm
> - google,gs101-cmu-misc
> + - google,gs101-cmu-peric0
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> clock-names:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
>
> "#clock-cells":
> const: 1
> @@ -88,6 +89,26 @@ allOf:
> - const: dout_cmu_misc_bus
> - const: dout_cmu_misc_sss
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: google,gs101-cmu-peric0
> +
> + then:
> + properties:
> + clocks:
> + items:
> + - description: External reference clock (24.576 MHz)
> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> +
> + clock-names:
> + items:
> + - const: oscclk
> + - const: dout_cmu_peric0_bus
> + - const: dout_cmu_peric0_ip
'bus' and 'ip' are sufficient because naming is local to the module. The
same is true on 'dout_cmu_misc_bus'. As that has not made a release,
please fix all of them.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
2023-12-20 14:22 ` Tudor Ambarus
@ 2023-12-20 15:12 ` Sam Protsenko
-1 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-20 15:12 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Wed, Dec 20, 2023 at 8:22 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Hi, Sam!
>
> On 12/19/23 17:31, Sam Protsenko wrote:
> > On Tue, Dec 19, 2023 at 10:47 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Hi, Sam!
> >>
> >> On 12/14/23 16:43, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/14/23 16:09, Sam Protsenko wrote:
> >>>>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 12/14/23 15:37, Sam Protsenko wrote:
> >>>>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>>>>>
> >>>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>>>>>> which then makes the system hang. To prevent this, mark
> >>>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>>>>>> accordingly when tested.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >>>>>>>> ---
> >>>>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>>>>> 21, 0, 0),
> >>>>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>>>>>
> >>>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>>>>>> usually should be avoided. Is it possible that the system freezes
> >>>>>>> because some other clock (which depends on peric0_ip) gets disabled as
> >>>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>>>>>> is not implemented yet in the clock driver? Just looks weird to me
> >>>>>>> that the system hangs because of CMU IP clock disablement. It's
> >>>>>>> usually something much more specific.
> >>>>>>
> >>>>>> The system hang happened when I tested USI8 in I2C configuration with an
> >>>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >>>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >>>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >>>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
> >>>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >>>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>>>>>
> >>>>>
> >>>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
> >>>>
> >>>> yes.
> >>
> >> I checked again all the clocks. I implemented all but one, the one
> >> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
> >> don't have any reference on how it should be defined so I won't touch it
> >> yet. But I have some good news too, see below.
> >>
> >>>
> >>> Ok. Are there any other CMUs (perhaps not implemented yet) which
> >>> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> >>> clocks derived from it? If so, is there a chance some particular leaf
> >>> clock in those CMUs actually renders the system frozen when disabled
> >>> as a consequence of disabling PERIC0_IP, and would explain better why
> >>> the freeze happens?
> >>>
> >>> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> >>> because as you said you implemented all clocks in this CMU and neither
> >>> of those looks like a critical one. But I'd advice to add a TODO
> >>> comment saying it's probably a temporary solution before actual leaf
> >>> clock which leads to freeze is identified (which probably resides in
> >>> some other not implemented yet CMU).
> >>>
> >>>>
> >>>>> is a chance some other leaf clock (which is not implemented yet in
> >>>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
> >>>>> might actually lead to that hang you observe. Usually it's some
> >>>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> >>>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> >>>>> and the corresponding comments I left there, maybe it'll give you more
> >>>>> particular idea about what to look for. Yes, making the whole CMU
> >>>>> always running without understanding why (i.e. because of which
> >>>>> particular leaf clock) might not be the best way of handling this
> >>>>
> >>>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> >>>
> >>> That's not a root cause here. And I think PERIC0_IP is neither.
> >>>
> >>
> >> you were right!
> >>>>
> >>>>> issue. I might be mistaken, but at least please check if you
> >>>>> implemented all clocks for PERIC0 first and if making some meaningful
> >>>>> leaf clock critical makes more sense.
> >>>>>
> >>
> >> I determined which leaf clocks shall be marked as critical. I enabled
> >> the debugfs clock write access. Then I made sure that the parents of the
> >> PERIC0 CMU have at least one user so that they don't get disabled after
> >> an enable-disable sequence on a leaf clock. The I took all the PERIC0
> >> gate clocks and enabled and disabled them one by one. Whichever hang the
> >> system when the clock was disabled was marked as critical. The list of
> >> critical leaf clocks is as following:
> >>
> >
> > Nice! I used somehow similar procedure for clk-exynos850, doing
> > basically the same thing, but in core clock driver code.
> >
> >> "gout_peric0_peric0_cmu_peric0_pclk",
> >> "gout_peric0_lhm_axi_p_peric0_i_clk",
> >> "gout_peric0_peric0_top1_ipclk_0",
> >> "gout_peric0_peric0_top1_pclk_0".
> >>
> >> I'll update v2 with this instead. Thanks for the help, Sam!
> >
> > Glad you weren't discouraged by my meticulousness :) In clk-exynos850
> > I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
> > case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
> > clocks usually can be used to disable the bus clock for corresponding
> > CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
> > access the registers from that CMU block, as its register interface is
> > not clocked anymore. Guess I saw something similar in Exynos5433 or
> > Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
> > -- don't really remember. For AXI clock it also seems logical to keep
> > it running (AXI bus might be used for GIC and memory). But again,
> > maybe CLK_IGNORE_UNUSED flag would be more appropriate that
> > CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
> > exactly they do. Is TOP1 some other CMU or block name, and is there
> > any further users for those clocks?
> >
> > Anyways, if you are working on v2, please consider doing next two
> > things while at it:
> >
> > 1. For each critical clock: add corresponding comment explaining why
> > it's marked so
>
> Will do.
>
> > 2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
> > appropriate; both have their use in different cases
> >
> > Btw, if you check other Exynos clk drivers, there is a lot of examples
> > for flags like those.
> >
> Thanks for the feedback, it's educative.
>
> I played a little with the clk debugfs and I think all should be marked
> as critical. What I did was to make sure that their parents are enabled
> already and then I enabled and disabled each. Each time I disabled one
> of them the system hung. Thus in case they will be used, if one disable
> them on an error path, it will hang the system. We can't disable them at
> suspend either. Thus I propose to keep them as critical.
>
Do you see those clocks potentially used by some actual consumers in
future? If no, maybe CLK_IGNORE_UNUSED is enough (just to make sure
the core clock framework won't disable those during the clocks
initialization)? Anyway, I don't have any strong preferences in this
case. If you think CLK_IS_CRITICAL is better in this case, I'd say go
for it.
Also, on a bit different note: please make sure there is no
"clk_ignore_unused" param in your kernel cmdline (e.g. passed from the
bootloader via dts). The clock driver should be functional without
that param. Though it might take some additional work.
> Thanks!
> ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical
@ 2023-12-20 15:12 ` Sam Protsenko
0 siblings, 0 replies; 122+ messages in thread
From: Sam Protsenko @ 2023-12-20 15:12 UTC (permalink / raw)
To: Tudor Ambarus
Cc: peter.griffin, robh+dt, krzysztof.kozlowski+dt, mturquette,
sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
On Wed, Dec 20, 2023 at 8:22 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Hi, Sam!
>
> On 12/19/23 17:31, Sam Protsenko wrote:
> > On Tue, Dec 19, 2023 at 10:47 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>
> >> Hi, Sam!
> >>
> >> On 12/14/23 16:43, Sam Protsenko wrote:
> >>> On Thu, Dec 14, 2023 at 10:15 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 12/14/23 16:09, Sam Protsenko wrote:
> >>>>> On Thu, Dec 14, 2023 at 10:01 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 12/14/23 15:37, Sam Protsenko wrote:
> >>>>>>> On Thu, Dec 14, 2023 at 4:52 AM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> >>>>>>>>
> >>>>>>>> Testing USI8 I2C with an eeprom revealed that when the USI8 leaf clock
> >>>>>>>> is disabled it leads to the CMU_TOP PERIC0 IP gate clock disablement,
> >>>>>>>> which then makes the system hang. To prevent this, mark
> >>>>>>>> CLK_GOUT_CMU_PERIC0_IP as critical. Other clocks will be marked
> >>>>>>>> accordingly when tested.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >>>>>>>> ---
> >>>>>>>> drivers/clk/samsung/clk-gs101.c | 2 +-
> >>>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> index 3d194520b05e..08d80fca9cd6 100644
> >>>>>>>> --- a/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> +++ b/drivers/clk/samsung/clk-gs101.c
> >>>>>>>> @@ -1402,7 +1402,7 @@ static const struct samsung_gate_clock cmu_top_gate_clks[] __initconst = {
> >>>>>>>> "mout_cmu_peric0_bus", CLK_CON_GAT_GATE_CLKCMU_PERIC0_BUS,
> >>>>>>>> 21, 0, 0),
> >>>>>>>> GATE(CLK_GOUT_CMU_PERIC0_IP, "gout_cmu_peric0_ip", "mout_cmu_peric0_ip",
> >>>>>>>> - CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, 0, 0),
> >>>>>>>> + CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP, 21, CLK_IS_CRITICAL, 0),
> >>>>>>>
> >>>>>>> This clock doesn't seem like a leaf clock. It's also not a bus clock.
> >>>>>>> Leaving it always running makes the whole PERIC0 CMU clocked, which
> >>>>>>> usually should be avoided. Is it possible that the system freezes
> >>>>>>> because some other clock (which depends on peric0_ip) gets disabled as
> >>>>>>> a consequence of disabling peric0_ip? Maybe it's some leaf clock which
> >>>>>>> is not implemented yet in the clock driver? Just looks weird to me
> >>>>>>> that the system hangs because of CMU IP clock disablement. It's
> >>>>>>> usually something much more specific.
> >>>>>>
> >>>>>> The system hang happened when I tested USI8 in I2C configuration with an
> >>>>>> eeprom. After the eeprom is read the leaf gate clock that gets disabled
> >>>>>> is the one on PERIC0 (CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK). I assume
> >>>>>> this leads to the CMU_TOP gate (CLK_CON_GAT_GATE_CLKCMU_PERIC0_IP)
> >>>>>> disablement which makes the system hang. Either marking the CMU_TOP gate
> >>>>>> clock as critical (as I did in this patch) or marking the leaf PERIC0
> >>>>>> gate clock as critical, gets rid of the system hang. Did I choose wrong?
> >>>>>>
> >>>>>
> >>>>> Did you already implement 100% of clocks in CMU_PERIC0? If no, there
> >>>>
> >>>> yes.
> >>
> >> I checked again all the clocks. I implemented all but one, the one
> >> defined by the CLK_CON_BUF_CLKBUF_PERIC0_IP register. Unfortunately I
> >> don't have any reference on how it should be defined so I won't touch it
> >> yet. But I have some good news too, see below.
> >>
> >>>
> >>> Ok. Are there any other CMUs (perhaps not implemented yet) which
> >>> consume clocks from CMU_PERIC0, specifically PERIC0_IP clock or some
> >>> clocks derived from it? If so, is there a chance some particular leaf
> >>> clock in those CMUs actually renders the system frozen when disabled
> >>> as a consequence of disabling PERIC0_IP, and would explain better why
> >>> the freeze happens?
> >>>
> >>> For now I think it's ok to have that CLK_IS_CRITICAL flag here,
> >>> because as you said you implemented all clocks in this CMU and neither
> >>> of those looks like a critical one. But I'd advice to add a TODO
> >>> comment saying it's probably a temporary solution before actual leaf
> >>> clock which leads to freeze is identified (which probably resides in
> >>> some other not implemented yet CMU).
> >>>
> >>>>
> >>>>> is a chance some other leaf clock (which is not implemented yet in
> >>>>> your driver) gets disabled as a result of PERIC0_IP disablement, which
> >>>>> might actually lead to that hang you observe. Usually it's some
> >>>>> meaningful leaf clock, e.g. GIC or interconnect clocks. Please check
> >>>>> clk-exynos850.c driver for CLK_IS_CRITICAL and CLK_IGNORE_UNUSED flags
> >>>>> and the corresponding comments I left there, maybe it'll give you more
> >>>>> particular idea about what to look for. Yes, making the whole CMU
> >>>>> always running without understanding why (i.e. because of which
> >>>>> particular leaf clock) might not be the best way of handling this
> >>>>
> >>>> because of CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK
> >>>
> >>> That's not a root cause here. And I think PERIC0_IP is neither.
> >>>
> >>
> >> you were right!
> >>>>
> >>>>> issue. I might be mistaken, but at least please check if you
> >>>>> implemented all clocks for PERIC0 first and if making some meaningful
> >>>>> leaf clock critical makes more sense.
> >>>>>
> >>
> >> I determined which leaf clocks shall be marked as critical. I enabled
> >> the debugfs clock write access. Then I made sure that the parents of the
> >> PERIC0 CMU have at least one user so that they don't get disabled after
> >> an enable-disable sequence on a leaf clock. The I took all the PERIC0
> >> gate clocks and enabled and disabled them one by one. Whichever hang the
> >> system when the clock was disabled was marked as critical. The list of
> >> critical leaf clocks is as following:
> >>
> >
> > Nice! I used somehow similar procedure for clk-exynos850, doing
> > basically the same thing, but in core clock driver code.
> >
> >> "gout_peric0_peric0_cmu_peric0_pclk",
> >> "gout_peric0_lhm_axi_p_peric0_i_clk",
> >> "gout_peric0_peric0_top1_ipclk_0",
> >> "gout_peric0_peric0_top1_pclk_0".
> >>
> >> I'll update v2 with this instead. Thanks for the help, Sam!
> >
> > Glad you weren't discouraged by my meticulousness :) In clk-exynos850
> > I usually used CLK_IGNORE_UNUSED for clocks like XXX_CMU_XXX (in your
> > case it's PERIC0_CMU_PERIC0), with a corresponding comment. Those
> > clocks usually can be used to disable the bus clock for corresponding
> > CMU IP-core (in your case CMU_PERIC0), which makes it impossible to
> > access the registers from that CMU block, as its register interface is
> > not clocked anymore. Guess I saw something similar in Exynos5433 or
> > Exynos7 clk drivers, or maybe Sylwester or Krzysztof told me to do so
> > -- don't really remember. For AXI clock it also seems logical to keep
> > it running (AXI bus might be used for GIC and memory). But again,
> > maybe CLK_IGNORE_UNUSED flag would be more appropriate that
> > CLK_IS_CRITICAL? For the last two clocks -- it's hard to tell what
> > exactly they do. Is TOP1 some other CMU or block name, and is there
> > any further users for those clocks?
> >
> > Anyways, if you are working on v2, please consider doing next two
> > things while at it:
> >
> > 1. For each critical clock: add corresponding comment explaining why
> > it's marked so
>
> Will do.
>
> > 2. Consider using CLK_IGNORE_UNUSED instead of CLK_IS_CRITICAL when
> > appropriate; both have their use in different cases
> >
> > Btw, if you check other Exynos clk drivers, there is a lot of examples
> > for flags like those.
> >
> Thanks for the feedback, it's educative.
>
> I played a little with the clk debugfs and I think all should be marked
> as critical. What I did was to make sure that their parents are enabled
> already and then I enabled and disabled each. Each time I disabled one
> of them the system hung. Thus in case they will be used, if one disable
> them on an error path, it will hang the system. We can't disable them at
> suspend either. Thus I propose to keep them as critical.
>
Do you see those clocks potentially used by some actual consumers in
future? If no, maybe CLK_IGNORE_UNUSED is enough (just to make sure
the core clock framework won't disable those during the clocks
initialization)? Anyway, I don't have any strong preferences in this
case. If you think CLK_IS_CRITICAL is better in this case, I'd say go
for it.
Also, on a bit different note: please make sure there is no
"clk_ignore_unused" param in your kernel cmdline (e.g. passed from the
bootloader via dts). The clock driver should be functional without
that param. Though it might take some additional work.
> Thanks!
> ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-20 15:07 ` Rob Herring
@ 2023-12-21 7:20 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-21 7:20 UTC (permalink / raw)
To: Rob Herring
Cc: peter.griffin, krzysztof.kozlowski+dt, mturquette, sboyd,
conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/20/23 15:07, Rob Herring wrote:
> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>> clock management unit.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> index 3eebc03a309b..ba54c13c55bc 100644
>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> @@ -30,14 +30,15 @@ properties:
>> - google,gs101-cmu-top
>> - google,gs101-cmu-apm
>> - google,gs101-cmu-misc
>> + - google,gs101-cmu-peric0
>>
>> clocks:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>>
>> clock-names:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>>
>> "#clock-cells":
>> const: 1
>> @@ -88,6 +89,26 @@ allOf:
>> - const: dout_cmu_misc_bus
>> - const: dout_cmu_misc_sss
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: google,gs101-cmu-peric0
>> +
>> + then:
>> + properties:
>> + clocks:
>> + items:
>> + - description: External reference clock (24.576 MHz)
>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>> +
>> + clock-names:
>> + items:
>> + - const: oscclk
>> + - const: dout_cmu_peric0_bus
>> + - const: dout_cmu_peric0_ip
>
> 'bus' and 'ip' are sufficient because naming is local to the module. The
> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
> please fix all of them.
>
Ok, will fix them shortly. Thanks, Rob!
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-21 7:20 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-21 7:20 UTC (permalink / raw)
To: Rob Herring
Cc: peter.griffin, krzysztof.kozlowski+dt, mturquette, sboyd,
conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/20/23 15:07, Rob Herring wrote:
> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>> clock management unit.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> index 3eebc03a309b..ba54c13c55bc 100644
>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>> @@ -30,14 +30,15 @@ properties:
>> - google,gs101-cmu-top
>> - google,gs101-cmu-apm
>> - google,gs101-cmu-misc
>> + - google,gs101-cmu-peric0
>>
>> clocks:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>>
>> clock-names:
>> minItems: 1
>> - maxItems: 2
>> + maxItems: 3
>>
>> "#clock-cells":
>> const: 1
>> @@ -88,6 +89,26 @@ allOf:
>> - const: dout_cmu_misc_bus
>> - const: dout_cmu_misc_sss
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: google,gs101-cmu-peric0
>> +
>> + then:
>> + properties:
>> + clocks:
>> + items:
>> + - description: External reference clock (24.576 MHz)
>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>> +
>> + clock-names:
>> + items:
>> + - const: oscclk
>> + - const: dout_cmu_peric0_bus
>> + - const: dout_cmu_peric0_ip
>
> 'bus' and 'ip' are sufficient because naming is local to the module. The
> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
> please fix all of them.
>
Ok, will fix them shortly. Thanks, Rob!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
2023-12-15 8:01 ` Krzysztof Kozlowski
@ 2023-12-21 7:41 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-21 7:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/15/23 08:01, Krzysztof Kozlowski wrote:
> On 14/12/2023 15:31, Tudor Ambarus wrote:
>>
>>
>> On 12/14/23 14:19, Arnd Bergmann wrote:
>>> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>>>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>>>
>>>>
>>>> It works if in device tree one specifies the reg-io-width property and
>>>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>>>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>>>> unusable.
>>>
>>> In the case of incorrect DT data like a missing reg-io-width property,
>>> I would expect it to still fail once the regular console or tty takes
>>> over from earlycon.
>>>
>>>> Also, if the earlycon comes specified from the kernel params, the
>>>> of_setup_earlycon() is no longer called and the earlycon will be set
>>>> solely based on the kernel params buffer, thus allowing users to crash
>>>> the kernel on wrong earlycon definitions.
>>>
>>> But that in turn is the same as specifying any other incorrect earlycon.
>>
>> I don't think you can crash the kernel if you use other earlycon as you
>> don't make accesses on the 32bit restricted bus. But I agree that if
>> using the correct earlycon name, and mmio instead mmio32, is equivalent
>> to not specifying reg-io-width in dt.
>>
>>>
>>>> If you think the change is fine, I can amend the commit message with the
>>>> description from above.
>>>
>>> I'm still not convinced we need a special case here when everything else
>>> just requires passing the correct data.
>
> We shouldn't need any data from DT for this case, because this property
> apparently can be inferred from the compatible. IOW, GS101 SoC requires
> reg-io-width=4, everywhere, for each node, thus there is no need to
> specify this property. It should be deduced from the compatible.
>
The entire peric0/1 block requires 32 bit data widths indeed. PERIC is
used by the Universal Serial Interface (USI) and I3C. I've checked few
other hardware blocks and all require 32 bit data widths (G3D, TPU, TNR,
PERIC, PDP, MFC, MCSC, IPP, HSI, GSA and I stopped here).
If the reg-io-width shall be inferred from the compatible in the gs101
case, then this patch stands. I'll update the serial driver as well.
Thanks,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support
@ 2023-12-21 7:41 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-21 7:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, Arnd Bergmann, Peter Griffin, Rob Herring,
krzysztof.kozlowski+dt, Michael Turquette, Stephen Boyd,
Conor Dooley, andi.shyti, Alim Akhtar, Greg Kroah-Hartman,
Jiri Slaby, Catalin Marinas, Will Deacon, Sylwester Nawrocki,
Tomasz Figa, Chanwoo Choi, Sam Protsenko
Cc: André Draszik, saravanak, William McVicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/15/23 08:01, Krzysztof Kozlowski wrote:
> On 14/12/2023 15:31, Tudor Ambarus wrote:
>>
>>
>> On 12/14/23 14:19, Arnd Bergmann wrote:
>>> On Thu, Dec 14, 2023, at 13:52, Tudor Ambarus wrote:
>>>> On 12/14/23 12:01, Arnd Bergmann wrote:
>>>>> On Thu, Dec 14, 2023, at 11:52, Tudor Ambarus wrote:
>>>>>> +static int __init gs101_early_console_setup(struct earlycon_device *device,
>>>>>
>>>>
>>>> It works if in device tree one specifies the reg-io-width property and
>>>> sets it to 4. If the reg-io-width is not specified, the iotype defaults
>>>> to UPIO_MEM causing the SError interrupt on gs101 which makes the system
>>>> unusable.
>>>
>>> In the case of incorrect DT data like a missing reg-io-width property,
>>> I would expect it to still fail once the regular console or tty takes
>>> over from earlycon.
>>>
>>>> Also, if the earlycon comes specified from the kernel params, the
>>>> of_setup_earlycon() is no longer called and the earlycon will be set
>>>> solely based on the kernel params buffer, thus allowing users to crash
>>>> the kernel on wrong earlycon definitions.
>>>
>>> But that in turn is the same as specifying any other incorrect earlycon.
>>
>> I don't think you can crash the kernel if you use other earlycon as you
>> don't make accesses on the 32bit restricted bus. But I agree that if
>> using the correct earlycon name, and mmio instead mmio32, is equivalent
>> to not specifying reg-io-width in dt.
>>
>>>
>>>> If you think the change is fine, I can amend the commit message with the
>>>> description from above.
>>>
>>> I'm still not convinced we need a special case here when everything else
>>> just requires passing the correct data.
>
> We shouldn't need any data from DT for this case, because this property
> apparently can be inferred from the compatible. IOW, GS101 SoC requires
> reg-io-width=4, everywhere, for each node, thus there is no need to
> specify this property. It should be deduced from the compatible.
>
The entire peric0/1 block requires 32 bit data widths indeed. PERIC is
used by the Universal Serial Interface (USI) and I3C. I've checked few
other hardware blocks and all require 32 bit data widths (G3D, TPU, TNR,
PERIC, PDP, MFC, MCSC, IPP, HSI, GSA and I stopped here).
If the reg-io-width shall be inferred from the compatible in the gs101
case, then this patch stands. I'll update the serial driver as well.
Thanks,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-21 7:20 ` Tudor Ambarus
@ 2023-12-22 17:56 ` Peter Griffin
-1 siblings, 0 replies; 122+ messages in thread
From: Peter Griffin @ 2023-12-22 17:56 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rob Herring, krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt,
andi.shyti, alim.akhtar, gregkh, jirislaby, catalin.marinas,
will, s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi Tudor,
On Thu, 21 Dec 2023 at 07:20, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/20/23 15:07, Rob Herring wrote:
> > On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
> >> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> >> clock management unit.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
> >> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
> >> 2 files changed, 109 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> index 3eebc03a309b..ba54c13c55bc 100644
> >> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> @@ -30,14 +30,15 @@ properties:
> >> - google,gs101-cmu-top
> >> - google,gs101-cmu-apm
> >> - google,gs101-cmu-misc
> >> + - google,gs101-cmu-peric0
> >>
> >> clocks:
> >> minItems: 1
> >> - maxItems: 2
> >> + maxItems: 3
> >>
> >> clock-names:
> >> minItems: 1
> >> - maxItems: 2
> >> + maxItems: 3
> >>
> >> "#clock-cells":
> >> const: 1
> >> @@ -88,6 +89,26 @@ allOf:
> >> - const: dout_cmu_misc_bus
> >> - const: dout_cmu_misc_sss
> >>
> >> + - if:
> >> + properties:
> >> + compatible:
> >> + contains:
> >> + const: google,gs101-cmu-peric0
> >> +
> >> + then:
> >> + properties:
> >> + clocks:
> >> + items:
> >> + - description: External reference clock (24.576 MHz)
> >> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> >> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> >> +
> >> + clock-names:
> >> + items:
> >> + - const: oscclk
> >> + - const: dout_cmu_peric0_bus
> >> + - const: dout_cmu_peric0_ip
> >
> > 'bus' and 'ip' are sufficient because naming is local to the module. The
> > same is true on 'dout_cmu_misc_bus'. As that has not made a release,
> > please fix all of them.
> >
>
> Ok, will fix them shortly. Thanks, Rob!
With Robs review comments addressed feel free to add my:
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-22 17:56 ` Peter Griffin
0 siblings, 0 replies; 122+ messages in thread
From: Peter Griffin @ 2023-12-22 17:56 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rob Herring, krzysztof.kozlowski+dt, mturquette, sboyd, conor+dt,
andi.shyti, alim.akhtar, gregkh, jirislaby, catalin.marinas,
will, s.nawrocki, tomasz.figa, cw00.choi, arnd, semen.protsenko,
andre.draszik, saravanak, willmcvicker, linux-arm-kernel,
linux-samsung-soc, linux-clk, devicetree, linux-kernel,
linux-i2c, linux-serial
Hi Tudor,
On Thu, 21 Dec 2023 at 07:20, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
>
>
> On 12/20/23 15:07, Rob Herring wrote:
> > On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
> >> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
> >> clock management unit.
> >>
> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> >> ---
> >> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
> >> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
> >> 2 files changed, 109 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> index 3eebc03a309b..ba54c13c55bc 100644
> >> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >> @@ -30,14 +30,15 @@ properties:
> >> - google,gs101-cmu-top
> >> - google,gs101-cmu-apm
> >> - google,gs101-cmu-misc
> >> + - google,gs101-cmu-peric0
> >>
> >> clocks:
> >> minItems: 1
> >> - maxItems: 2
> >> + maxItems: 3
> >>
> >> clock-names:
> >> minItems: 1
> >> - maxItems: 2
> >> + maxItems: 3
> >>
> >> "#clock-cells":
> >> const: 1
> >> @@ -88,6 +89,26 @@ allOf:
> >> - const: dout_cmu_misc_bus
> >> - const: dout_cmu_misc_sss
> >>
> >> + - if:
> >> + properties:
> >> + compatible:
> >> + contains:
> >> + const: google,gs101-cmu-peric0
> >> +
> >> + then:
> >> + properties:
> >> + clocks:
> >> + items:
> >> + - description: External reference clock (24.576 MHz)
> >> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
> >> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
> >> +
> >> + clock-names:
> >> + items:
> >> + - const: oscclk
> >> + - const: dout_cmu_peric0_bus
> >> + - const: dout_cmu_peric0_ip
> >
> > 'bus' and 'ip' are sufficient because naming is local to the module. The
> > same is true on 'dout_cmu_misc_bus'. As that has not made a release,
> > please fix all of them.
> >
>
> Ok, will fix them shortly. Thanks, Rob!
With Robs review comments addressed feel free to add my:
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-21 7:20 ` Tudor Ambarus
@ 2023-12-27 12:38 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-27 12:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Peter Griffin
Cc: sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial, André Draszik
Hi, Rob,
On 12/21/23 07:20, Tudor Ambarus wrote:
>
>
> On 12/20/23 15:07, Rob Herring wrote:
>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>> clock management unit.
>>>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> ---
>>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> index 3eebc03a309b..ba54c13c55bc 100644
>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> @@ -30,14 +30,15 @@ properties:
>>> - google,gs101-cmu-top
>>> - google,gs101-cmu-apm
>>> - google,gs101-cmu-misc
>>> + - google,gs101-cmu-peric0
>>>
>>> clocks:
>>> minItems: 1
>>> - maxItems: 2
>>> + maxItems: 3
>>>
>>> clock-names:
>>> minItems: 1
>>> - maxItems: 2
>>> + maxItems: 3
>>>
>>> "#clock-cells":
>>> const: 1
>>> @@ -88,6 +89,26 @@ allOf:
>>> - const: dout_cmu_misc_bus
>>> - const: dout_cmu_misc_sss
>>>
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: google,gs101-cmu-peric0
>>> +
>>> + then:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: External reference clock (24.576 MHz)
>>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: oscclk
>>> + - const: dout_cmu_peric0_bus
>>> + - const: dout_cmu_peric0_ip
>>
>> 'bus' and 'ip' are sufficient because naming is local to the module. The
>> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
>> please fix all of them.
>>
>
> Ok, will fix them shortly. Thanks, Rob!
I tried your suggestion at
https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org/
and we noticed that we'd have to update the clock driver as well.
These CMUs set the DT clock-name of the parent clock in the driver in
struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
parent clock based on the clock-name in exynos_arm64_register_cmu().
In order to enable the parent clock of the CMU the following would be
needed in the driver:
diff --git a/drivers/clk/samsung/clk-gs101.c
b/drivers/clk/samsung/clk-gs101.c
index 68a27b78b00b..e91836ea3a98 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
__initconst = {
.nr_clk_ids = CLKS_NR_MISC,
.clk_regs = misc_clk_regs,
.nr_clk_regs = ARRAY_SIZE(misc_clk_regs),
- .clk_name = "dout_cmu_misc_bus",
+ .clk_name = "bus",
};
I think I lean towards keeping the name as it was because it's clearer
what are the clock dependencies in the driver. "dout_cmu_misc_bus" is
the clock name used when defining the clock:
DIV(CLK_DOUT_CMU_MISC_BUS, "dout_cmu_misc_bus", "gout_cmu_misc_bus",
CLK_CON_DIV_CLKCMU_MISC_BUS, 0, 4),
The other exynos clock drivers are using too the driver's clock names
for the clock-names device tree property. For consistency I'd keep it
the same.
If you have a stronger opinion than mine, please tell and I'll happily
update the driver.
Thanks,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-27 12:38 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-27 12:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Peter Griffin
Cc: sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial, André Draszik
Hi, Rob,
On 12/21/23 07:20, Tudor Ambarus wrote:
>
>
> On 12/20/23 15:07, Rob Herring wrote:
>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>> clock management unit.
>>>
>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>> ---
>>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> index 3eebc03a309b..ba54c13c55bc 100644
>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>> @@ -30,14 +30,15 @@ properties:
>>> - google,gs101-cmu-top
>>> - google,gs101-cmu-apm
>>> - google,gs101-cmu-misc
>>> + - google,gs101-cmu-peric0
>>>
>>> clocks:
>>> minItems: 1
>>> - maxItems: 2
>>> + maxItems: 3
>>>
>>> clock-names:
>>> minItems: 1
>>> - maxItems: 2
>>> + maxItems: 3
>>>
>>> "#clock-cells":
>>> const: 1
>>> @@ -88,6 +89,26 @@ allOf:
>>> - const: dout_cmu_misc_bus
>>> - const: dout_cmu_misc_sss
>>>
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: google,gs101-cmu-peric0
>>> +
>>> + then:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: External reference clock (24.576 MHz)
>>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: oscclk
>>> + - const: dout_cmu_peric0_bus
>>> + - const: dout_cmu_peric0_ip
>>
>> 'bus' and 'ip' are sufficient because naming is local to the module. The
>> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
>> please fix all of them.
>>
>
> Ok, will fix them shortly. Thanks, Rob!
I tried your suggestion at
https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org/
and we noticed that we'd have to update the clock driver as well.
These CMUs set the DT clock-name of the parent clock in the driver in
struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
parent clock based on the clock-name in exynos_arm64_register_cmu().
In order to enable the parent clock of the CMU the following would be
needed in the driver:
diff --git a/drivers/clk/samsung/clk-gs101.c
b/drivers/clk/samsung/clk-gs101.c
index 68a27b78b00b..e91836ea3a98 100644
--- a/drivers/clk/samsung/clk-gs101.c
+++ b/drivers/clk/samsung/clk-gs101.c
@@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
__initconst = {
.nr_clk_ids = CLKS_NR_MISC,
.clk_regs = misc_clk_regs,
.nr_clk_regs = ARRAY_SIZE(misc_clk_regs),
- .clk_name = "dout_cmu_misc_bus",
+ .clk_name = "bus",
};
I think I lean towards keeping the name as it was because it's clearer
what are the clock dependencies in the driver. "dout_cmu_misc_bus" is
the clock name used when defining the clock:
DIV(CLK_DOUT_CMU_MISC_BUS, "dout_cmu_misc_bus", "gout_cmu_misc_bus",
CLK_CON_DIV_CLKCMU_MISC_BUS, 0, 4),
The other exynos clock drivers are using too the driver's clock names
for the clock-names device tree property. For consistency I'd keep it
the same.
If you have a stronger opinion than mine, please tell and I'll happily
update the driver.
Thanks,
ta
^ permalink raw reply related [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-27 12:38 ` Tudor Ambarus
@ 2023-12-28 7:30 ` Krzysztof Kozlowski
-1 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-28 7:30 UTC (permalink / raw)
To: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, Peter Griffin
Cc: sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 27/12/2023 13:38, Tudor Ambarus wrote:
> Hi, Rob,
>
> On 12/21/23 07:20, Tudor Ambarus wrote:
>>
>>
>> On 12/20/23 15:07, Rob Herring wrote:
>>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>>> clock management unit.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> ---
>>>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>>>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>>>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> index 3eebc03a309b..ba54c13c55bc 100644
>>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> @@ -30,14 +30,15 @@ properties:
>>>> - google,gs101-cmu-top
>>>> - google,gs101-cmu-apm
>>>> - google,gs101-cmu-misc
>>>> + - google,gs101-cmu-peric0
>>>>
>>>> clocks:
>>>> minItems: 1
>>>> - maxItems: 2
>>>> + maxItems: 3
>>>>
>>>> clock-names:
>>>> minItems: 1
>>>> - maxItems: 2
>>>> + maxItems: 3
>>>>
>>>> "#clock-cells":
>>>> const: 1
>>>> @@ -88,6 +89,26 @@ allOf:
>>>> - const: dout_cmu_misc_bus
>>>> - const: dout_cmu_misc_sss
>>>>
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + const: google,gs101-cmu-peric0
>>>> +
>>>> + then:
>>>> + properties:
>>>> + clocks:
>>>> + items:
>>>> + - description: External reference clock (24.576 MHz)
>>>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: oscclk
>>>> + - const: dout_cmu_peric0_bus
>>>> + - const: dout_cmu_peric0_ip
>>>
>>> 'bus' and 'ip' are sufficient because naming is local to the module. The
>>> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
>>> please fix all of them.
>>>
>>
>> Ok, will fix them shortly. Thanks, Rob!
>
> I tried your suggestion at
> https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org/
>
> and we noticed that we'd have to update the clock driver as well.
> These CMUs set the DT clock-name of the parent clock in the driver in
> struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
> parent clock based on the clock-name in exynos_arm64_register_cmu().
>
> In order to enable the parent clock of the CMU the following would be
> needed in the driver:
>
> diff --git a/drivers/clk/samsung/clk-gs101.c
> b/drivers/clk/samsung/clk-gs101.c
> index 68a27b78b00b..e91836ea3a98 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
> __initconst = {
> .nr_clk_ids = CLKS_NR_MISC,
> .clk_regs = misc_clk_regs,
> .nr_clk_regs = ARRAY_SIZE(misc_clk_regs),
> - .clk_name = "dout_cmu_misc_bus",
> + .clk_name = "bus",
Yes, obviously, the names are used...
The entire point was that a week ago Rob said:
"As that has not made a release, please fix all of them."
but if you keep waiting, like 8 days for this simple patch, his
statement is not true anymore.
The only point was to send a fix *the next day*, so I would apply it and
send further. You kind of solved that problem by waiting entire week for
a simple driver and DTS change.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-28 7:30 ` Krzysztof Kozlowski
0 siblings, 0 replies; 122+ messages in thread
From: Krzysztof Kozlowski @ 2023-12-28 7:30 UTC (permalink / raw)
To: Tudor Ambarus, Rob Herring, Krzysztof Kozlowski, Peter Griffin
Cc: sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 27/12/2023 13:38, Tudor Ambarus wrote:
> Hi, Rob,
>
> On 12/21/23 07:20, Tudor Ambarus wrote:
>>
>>
>> On 12/20/23 15:07, Rob Herring wrote:
>>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>>> clock management unit.
>>>>
>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>> ---
>>>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>>>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>>>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> index 3eebc03a309b..ba54c13c55bc 100644
>>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>> @@ -30,14 +30,15 @@ properties:
>>>> - google,gs101-cmu-top
>>>> - google,gs101-cmu-apm
>>>> - google,gs101-cmu-misc
>>>> + - google,gs101-cmu-peric0
>>>>
>>>> clocks:
>>>> minItems: 1
>>>> - maxItems: 2
>>>> + maxItems: 3
>>>>
>>>> clock-names:
>>>> minItems: 1
>>>> - maxItems: 2
>>>> + maxItems: 3
>>>>
>>>> "#clock-cells":
>>>> const: 1
>>>> @@ -88,6 +89,26 @@ allOf:
>>>> - const: dout_cmu_misc_bus
>>>> - const: dout_cmu_misc_sss
>>>>
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + const: google,gs101-cmu-peric0
>>>> +
>>>> + then:
>>>> + properties:
>>>> + clocks:
>>>> + items:
>>>> + - description: External reference clock (24.576 MHz)
>>>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: oscclk
>>>> + - const: dout_cmu_peric0_bus
>>>> + - const: dout_cmu_peric0_ip
>>>
>>> 'bus' and 'ip' are sufficient because naming is local to the module. The
>>> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
>>> please fix all of them.
>>>
>>
>> Ok, will fix them shortly. Thanks, Rob!
>
> I tried your suggestion at
> https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org/
>
> and we noticed that we'd have to update the clock driver as well.
> These CMUs set the DT clock-name of the parent clock in the driver in
> struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
> parent clock based on the clock-name in exynos_arm64_register_cmu().
>
> In order to enable the parent clock of the CMU the following would be
> needed in the driver:
>
> diff --git a/drivers/clk/samsung/clk-gs101.c
> b/drivers/clk/samsung/clk-gs101.c
> index 68a27b78b00b..e91836ea3a98 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
> __initconst = {
> .nr_clk_ids = CLKS_NR_MISC,
> .clk_regs = misc_clk_regs,
> .nr_clk_regs = ARRAY_SIZE(misc_clk_regs),
> - .clk_name = "dout_cmu_misc_bus",
> + .clk_name = "bus",
Yes, obviously, the names are used...
The entire point was that a week ago Rob said:
"As that has not made a release, please fix all of them."
but if you keep waiting, like 8 days for this simple patch, his
statement is not true anymore.
The only point was to send a fix *the next day*, so I would apply it and
send further. You kind of solved that problem by waiting entire week for
a simple driver and DTS change.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
2023-12-28 7:30 ` Krzysztof Kozlowski
@ 2023-12-28 7:49 ` Tudor Ambarus
-1 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-28 7:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski, Peter Griffin
Cc: sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/28/23 07:30, Krzysztof Kozlowski wrote:
> On 27/12/2023 13:38, Tudor Ambarus wrote:
>> Hi, Rob,
>>
>> On 12/21/23 07:20, Tudor Ambarus wrote:
>>>
>>>
>>> On 12/20/23 15:07, Rob Herring wrote:
>>>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>>>> clock management unit.
>>>>>
>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>> ---
>>>>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>>>>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>>>>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> index 3eebc03a309b..ba54c13c55bc 100644
>>>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> @@ -30,14 +30,15 @@ properties:
>>>>> - google,gs101-cmu-top
>>>>> - google,gs101-cmu-apm
>>>>> - google,gs101-cmu-misc
>>>>> + - google,gs101-cmu-peric0
>>>>>
>>>>> clocks:
>>>>> minItems: 1
>>>>> - maxItems: 2
>>>>> + maxItems: 3
>>>>>
>>>>> clock-names:
>>>>> minItems: 1
>>>>> - maxItems: 2
>>>>> + maxItems: 3
>>>>>
>>>>> "#clock-cells":
>>>>> const: 1
>>>>> @@ -88,6 +89,26 @@ allOf:
>>>>> - const: dout_cmu_misc_bus
>>>>> - const: dout_cmu_misc_sss
>>>>>
>>>>> + - if:
>>>>> + properties:
>>>>> + compatible:
>>>>> + contains:
>>>>> + const: google,gs101-cmu-peric0
>>>>> +
>>>>> + then:
>>>>> + properties:
>>>>> + clocks:
>>>>> + items:
>>>>> + - description: External reference clock (24.576 MHz)
>>>>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>>>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>>>> +
>>>>> + clock-names:
>>>>> + items:
>>>>> + - const: oscclk
>>>>> + - const: dout_cmu_peric0_bus
>>>>> + - const: dout_cmu_peric0_ip
>>>>
>>>> 'bus' and 'ip' are sufficient because naming is local to the module. The
>>>> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
>>>> please fix all of them.
>>>>
>>>
>>> Ok, will fix them shortly. Thanks, Rob!
>>
>> I tried your suggestion at
>> https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org/
>>
>> and we noticed that we'd have to update the clock driver as well.
>> These CMUs set the DT clock-name of the parent clock in the driver in
>> struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
>> parent clock based on the clock-name in exynos_arm64_register_cmu().
>>
>> In order to enable the parent clock of the CMU the following would be
>> needed in the driver:
>>
>> diff --git a/drivers/clk/samsung/clk-gs101.c
>> b/drivers/clk/samsung/clk-gs101.c
>> index 68a27b78b00b..e91836ea3a98 100644
>> --- a/drivers/clk/samsung/clk-gs101.c
>> +++ b/drivers/clk/samsung/clk-gs101.c
>> @@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
>> __initconst = {
>> .nr_clk_ids = CLKS_NR_MISC,
>> .clk_regs = misc_clk_regs,
>> .nr_clk_regs = ARRAY_SIZE(misc_clk_regs),
>> - .clk_name = "dout_cmu_misc_bus",
>> + .clk_name = "bus",
>
> Yes, obviously, the names are used...
>
> The entire point was that a week ago Rob said:
> "As that has not made a release, please fix all of them."
> but if you keep waiting, like 8 days for this simple patch, his
> statement is not true anymore.
>
I saw the problem at the end of Thursday, reported it, and after that I
entered vacation.
> The only point was to send a fix *the next day*, so I would apply it and
> send further. You kind of solved that problem by waiting entire week for
> a simple driver and DTS change.
>
Why can't we queue the name fix as a patch for v6.8-rc1? Of course if
you consider that the change is worth it. As I said, I lean towards not
changing it.
Thanks,
ta
^ permalink raw reply [flat|nested] 122+ messages in thread
* Re: [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit
@ 2023-12-28 7:49 ` Tudor Ambarus
0 siblings, 0 replies; 122+ messages in thread
From: Tudor Ambarus @ 2023-12-28 7:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski, Peter Griffin
Cc: sboyd, conor+dt, andi.shyti, alim.akhtar, gregkh, jirislaby,
catalin.marinas, will, s.nawrocki, tomasz.figa, cw00.choi, arnd,
semen.protsenko, andre.draszik, saravanak, willmcvicker,
linux-arm-kernel, linux-samsung-soc, linux-clk, devicetree,
linux-kernel, linux-i2c, linux-serial
On 12/28/23 07:30, Krzysztof Kozlowski wrote:
> On 27/12/2023 13:38, Tudor Ambarus wrote:
>> Hi, Rob,
>>
>> On 12/21/23 07:20, Tudor Ambarus wrote:
>>>
>>>
>>> On 12/20/23 15:07, Rob Herring wrote:
>>>> On Thu, Dec 14, 2023 at 10:52:32AM +0000, Tudor Ambarus wrote:
>>>>> Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0)
>>>>> clock management unit.
>>>>>
>>>>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>>>>> ---
>>>>> .../bindings/clock/google,gs101-clock.yaml | 25 +++++-
>>>>> include/dt-bindings/clock/google,gs101.h | 86 +++++++++++++++++++
>>>>> 2 files changed, 109 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> index 3eebc03a309b..ba54c13c55bc 100644
>>>>> --- a/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> +++ b/Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>>>>> @@ -30,14 +30,15 @@ properties:
>>>>> - google,gs101-cmu-top
>>>>> - google,gs101-cmu-apm
>>>>> - google,gs101-cmu-misc
>>>>> + - google,gs101-cmu-peric0
>>>>>
>>>>> clocks:
>>>>> minItems: 1
>>>>> - maxItems: 2
>>>>> + maxItems: 3
>>>>>
>>>>> clock-names:
>>>>> minItems: 1
>>>>> - maxItems: 2
>>>>> + maxItems: 3
>>>>>
>>>>> "#clock-cells":
>>>>> const: 1
>>>>> @@ -88,6 +89,26 @@ allOf:
>>>>> - const: dout_cmu_misc_bus
>>>>> - const: dout_cmu_misc_sss
>>>>>
>>>>> + - if:
>>>>> + properties:
>>>>> + compatible:
>>>>> + contains:
>>>>> + const: google,gs101-cmu-peric0
>>>>> +
>>>>> + then:
>>>>> + properties:
>>>>> + clocks:
>>>>> + items:
>>>>> + - description: External reference clock (24.576 MHz)
>>>>> + - description: Connectivity Peripheral 0 bus clock (from CMU_TOP)
>>>>> + - description: Connectivity Peripheral 0 IP clock (from CMU_TOP)
>>>>> +
>>>>> + clock-names:
>>>>> + items:
>>>>> + - const: oscclk
>>>>> + - const: dout_cmu_peric0_bus
>>>>> + - const: dout_cmu_peric0_ip
>>>>
>>>> 'bus' and 'ip' are sufficient because naming is local to the module. The
>>>> same is true on 'dout_cmu_misc_bus'. As that has not made a release,
>>>> please fix all of them.
>>>>
>>>
>>> Ok, will fix them shortly. Thanks, Rob!
>>
>> I tried your suggestion at
>> https://lore.kernel.org/linux-arm-kernel/c6cc6e74-6c3d-439b-8dc1-bc50a88a3d8f@linaro.org/
>>
>> and we noticed that we'd have to update the clock driver as well.
>> These CMUs set the DT clock-name of the parent clock in the driver in
>> struct samsung_cmu_info::clk_name[]. The driver then tries to enable the
>> parent clock based on the clock-name in exynos_arm64_register_cmu().
>>
>> In order to enable the parent clock of the CMU the following would be
>> needed in the driver:
>>
>> diff --git a/drivers/clk/samsung/clk-gs101.c
>> b/drivers/clk/samsung/clk-gs101.c
>> index 68a27b78b00b..e91836ea3a98 100644
>> --- a/drivers/clk/samsung/clk-gs101.c
>> +++ b/drivers/clk/samsung/clk-gs101.c
>> @@ -2476,7 +2476,7 @@ static const struct samsung_cmu_info misc_cmu_info
>> __initconst = {
>> .nr_clk_ids = CLKS_NR_MISC,
>> .clk_regs = misc_clk_regs,
>> .nr_clk_regs = ARRAY_SIZE(misc_clk_regs),
>> - .clk_name = "dout_cmu_misc_bus",
>> + .clk_name = "bus",
>
> Yes, obviously, the names are used...
>
> The entire point was that a week ago Rob said:
> "As that has not made a release, please fix all of them."
> but if you keep waiting, like 8 days for this simple patch, his
> statement is not true anymore.
>
I saw the problem at the end of Thursday, reported it, and after that I
entered vacation.
> The only point was to send a fix *the next day*, so I would apply it and
> send further. You kind of solved that problem by waiting entire week for
> a simple driver and DTS change.
>
Why can't we queue the name fix as a patch for v6.8-rc1? Of course if
you consider that the change is worth it. As I said, I lean towards not
changing it.
Thanks,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 122+ messages in thread
end of thread, other threads:[~2023-12-28 7:50 UTC | newest]
Thread overview: 122+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-14 10:52 [PATCH 00/13] GS101 Oriole: CMU_PERIC0 support and USI updates Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 10:52 ` [PATCH 01/13] dt-bindings: clock: google,gs101: fix CMU_TOP gate clock names Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:07 ` Sam Protsenko
2023-12-14 15:07 ` Sam Protsenko
2023-12-14 15:16 ` Tudor Ambarus
2023-12-14 15:16 ` Tudor Ambarus
2023-12-14 15:22 ` Sam Protsenko
2023-12-14 15:22 ` Sam Protsenko
2023-12-14 16:04 ` Peter Griffin
2023-12-14 16:04 ` Peter Griffin
2023-12-15 8:13 ` Krzysztof Kozlowski
2023-12-15 8:13 ` Krzysztof Kozlowski
2023-12-15 10:23 ` Tudor Ambarus
2023-12-15 10:23 ` Tudor Ambarus
2023-12-15 19:24 ` Krzysztof Kozlowski
2023-12-15 19:24 ` Krzysztof Kozlowski
2023-12-15 19:25 ` Krzysztof Kozlowski
2023-12-15 19:25 ` Krzysztof Kozlowski
2023-12-18 6:50 ` Tudor Ambarus
2023-12-18 6:50 ` Tudor Ambarus
2023-12-14 10:52 ` [PATCH 02/13] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:12 ` Sam Protsenko
2023-12-14 15:12 ` Sam Protsenko
2023-12-20 15:07 ` Rob Herring
2023-12-20 15:07 ` Rob Herring
2023-12-21 7:20 ` Tudor Ambarus
2023-12-21 7:20 ` Tudor Ambarus
2023-12-22 17:56 ` Peter Griffin
2023-12-22 17:56 ` Peter Griffin
2023-12-27 12:38 ` Tudor Ambarus
2023-12-27 12:38 ` Tudor Ambarus
2023-12-28 7:30 ` Krzysztof Kozlowski
2023-12-28 7:30 ` Krzysztof Kozlowski
2023-12-28 7:49 ` Tudor Ambarus
2023-12-28 7:49 ` Tudor Ambarus
2023-12-14 10:52 ` [PATCH 03/13] dt-bindings: i2c: exynos5: add google,gs101-hsi2c compatible Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 13:06 ` Wolfram Sang
2023-12-14 13:06 ` Wolfram Sang
2023-12-14 15:12 ` Sam Protsenko
2023-12-14 15:12 ` Sam Protsenko
2023-12-15 19:42 ` Rob Herring
2023-12-15 19:42 ` Rob Herring
2023-12-14 10:52 ` [PATCH 04/13] dt-bindings: serial: samsung: gs101: make reg-io-width required property Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:14 ` Sam Protsenko
2023-12-14 15:14 ` Sam Protsenko
2023-12-15 7:58 ` Krzysztof Kozlowski
2023-12-15 7:58 ` Krzysztof Kozlowski
2023-12-14 10:52 ` [PATCH 05/13] tty: serial: samsung: add gs101 earlycon support Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 12:01 ` Arnd Bergmann
2023-12-14 12:01 ` Arnd Bergmann
2023-12-14 13:52 ` Tudor Ambarus
2023-12-14 13:52 ` Tudor Ambarus
2023-12-14 14:19 ` Arnd Bergmann
2023-12-14 14:19 ` Arnd Bergmann
2023-12-14 14:31 ` Tudor Ambarus
2023-12-14 14:31 ` Tudor Ambarus
2023-12-15 8:01 ` Krzysztof Kozlowski
2023-12-15 8:01 ` Krzysztof Kozlowski
2023-12-21 7:41 ` Tudor Ambarus
2023-12-21 7:41 ` Tudor Ambarus
2023-12-14 10:52 ` [PATCH 06/13] clk: samsung: gs101: add support for cmu_peric0 Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 10:52 ` [PATCH 07/13] clk: samsung: gs101: mark PERIC0 IP TOP gate clock as critical Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:37 ` Sam Protsenko
2023-12-14 15:37 ` Sam Protsenko
2023-12-14 16:01 ` Tudor Ambarus
2023-12-14 16:01 ` Tudor Ambarus
2023-12-14 16:09 ` Sam Protsenko
2023-12-14 16:09 ` Sam Protsenko
2023-12-14 16:15 ` Tudor Ambarus
2023-12-14 16:15 ` Tudor Ambarus
2023-12-14 16:43 ` Sam Protsenko
2023-12-14 16:43 ` Sam Protsenko
2023-12-19 16:47 ` Tudor Ambarus
2023-12-19 16:47 ` Tudor Ambarus
2023-12-19 17:31 ` Sam Protsenko
2023-12-19 17:31 ` Sam Protsenko
2023-12-20 14:22 ` Tudor Ambarus
2023-12-20 14:22 ` Tudor Ambarus
2023-12-20 15:12 ` Sam Protsenko
2023-12-20 15:12 ` Sam Protsenko
2023-12-14 10:52 ` [PATCH 08/13] arm64: dts: exynos: gs101: enable cmu-peric0 clock controller Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:39 ` Sam Protsenko
2023-12-14 15:39 ` Sam Protsenko
2023-12-15 8:02 ` Krzysztof Kozlowski
2023-12-15 8:02 ` Krzysztof Kozlowski
2023-12-14 10:52 ` [PATCH 09/13] arm64: dts: exynos: gs101: update USI UART to use peric0 clocks Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:42 ` Sam Protsenko
2023-12-14 15:42 ` Sam Protsenko
2023-12-14 10:52 ` [PATCH 10/13] arm64: dts: exynos: gs101: define USI8 with I2C configuration Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:51 ` Sam Protsenko
2023-12-14 15:51 ` Sam Protsenko
2023-12-15 8:04 ` Krzysztof Kozlowski
2023-12-15 8:04 ` Krzysztof Kozlowski
2023-12-14 10:52 ` [PATCH 11/13] arm64: dts: exynos: gs101: enable eeprom on gs101-oriole Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 15:55 ` Sam Protsenko
2023-12-14 15:55 ` Sam Protsenko
2023-12-15 8:07 ` Krzysztof Kozlowski
2023-12-15 8:07 ` Krzysztof Kozlowski
2023-12-14 10:52 ` [PATCH 12/13] arm64: defconfig: sync with savedefconfig Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 12:08 ` Arnd Bergmann
2023-12-14 12:08 ` Arnd Bergmann
2023-12-14 13:19 ` Krzysztof Kozlowski
2023-12-14 13:19 ` Krzysztof Kozlowski
2023-12-14 14:09 ` Tudor Ambarus
2023-12-14 14:09 ` Tudor Ambarus
2023-12-14 10:52 ` [PATCH 13/13] arm64: defconfig: make at24 eeprom builtin Tudor Ambarus
2023-12-14 10:52 ` Tudor Ambarus
2023-12-14 13:20 ` Krzysztof Kozlowski
2023-12-14 13:20 ` Krzysztof Kozlowski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.