Hi all,
Here are some fixes for v4.5 merge window to get dm814x-evm booting.
While hp t410 boots based on the bootloader clocks, dm814x-evm needs
more things configured. Especially the clock dts entries were all
wrong and just happened to be harmless on hp t410.
To boot, you probably want to use v4.4-rc3 because of commit 29f5b34ca1a1
("arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data") and also
manually apply commit 0db19b850468 ("net: cpsw: Fix ethernet regression
for dm814x") from Linux next.
I have more changes coming up after this series after I clean them
up a bit. Here's a brief status update for people:
What's working after this series on dm814x-evm and hp t410:
- Timers
- Serial
- Ethernet
- DMA
- I2C (only tested so far with i2cdetect -r 0)
- GPIO (only tested with additional MMC patches for card detect)
I have the following additional patches coming soonish:
- Basic ADPLL clock driver
- MMC support
- USB support
- Minimal j5eco-evm support
Should work with just configuration:
- [PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers
I'm not working on any of the accelerators or graphics FYI. If somebody
has patches coming for those please notify on the linux-omap and
linux-arm-kernel mailings lists so we can avoid duplicate work.
Cheers,
Tony
Tony Lindgren (10):
ARM: OMAP2+: Fix timer entries for dm814x
clk: ti: Add few dm814x clock aliases
ARM: OMAP2+: Add DPPLS clock manager for dm814x
ARM: OMAP2+: Enable GPIO for dm814x
ARM: OMAP2+: Disable GPIO softreset for dm81xx
ARM: OMAP2+: Remove useless check for legacy booting for dm814x
ARM: dts: Fix dm814x entries for pllss and prcm
ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
ARM: dts: Fix dm8148 control modules ranges
ARM: dts: Fix dm814x pinctrl address and mask
arch/arm/boot/dts/dm814x-clocks.dtsi | 109 +++++++++++++++++++++--------
arch/arm/boot/dts/dm814x.dtsi | 25 ++++---
arch/arm/mach-omap2/io.c | 3 +-
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 15 ++--
arch/arm/mach-omap2/prm_common.c | 6 ++
drivers/clk/ti/clk-814x.c | 4 ++
include/linux/clk/ti.h | 1 +
7 files changed, 117 insertions(+), 46 deletions(-)
--
2.6.2
There's a mux after the oscillator similar to am335x. I did not
notice this on hp t410 as it boots even with no clocks configured.
Cc: Paul Walmsley <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 6256052..d5246b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -599,7 +599,7 @@ static struct omap_timer_capability_dev_attr capability_alwon_dev_attr = {
static struct omap_hwmod dm814x_timer1_hwmod = {
.name = "timer1",
.clkdm_name = "alwon_l3s_clkdm",
- .main_clk = "timer_sys_ck",
+ .main_clk = "timer1_fck",
.dev_attr = &capability_alwon_dev_attr,
.class = &dm816x_timer_hwmod_class,
.flags = HWMOD_NO_IDLEST,
@@ -608,7 +608,7 @@ static struct omap_hwmod dm814x_timer1_hwmod = {
static struct omap_hwmod_ocp_if dm814x_l4_ls__timer1 = {
.master = &dm81xx_l4_ls_hwmod,
.slave = &dm814x_timer1_hwmod,
- .clk = "timer_sys_ck",
+ .clk = "timer1_fck",
.user = OCP_USER_MPU,
};
@@ -636,7 +636,7 @@ static struct omap_hwmod_ocp_if dm816x_l4_ls__timer1 = {
static struct omap_hwmod dm814x_timer2_hwmod = {
.name = "timer2",
.clkdm_name = "alwon_l3s_clkdm",
- .main_clk = "timer_sys_ck",
+ .main_clk = "timer2_fck",
.dev_attr = &capability_alwon_dev_attr,
.class = &dm816x_timer_hwmod_class,
.flags = HWMOD_NO_IDLEST,
@@ -645,7 +645,7 @@ static struct omap_hwmod dm814x_timer2_hwmod = {
static struct omap_hwmod_ocp_if dm814x_l4_ls__timer2 = {
.master = &dm81xx_l4_ls_hwmod,
.slave = &dm814x_timer2_hwmod,
- .clk = "timer_sys_ck",
+ .clk = "timer2_fck",
.user = OCP_USER_MPU,
};
--
2.6.2
The timer clock aliases are needed early on dm814x. Let's also
add the aliases for the interconnects and MMC.
Cc: Michael Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Cc: Tero Kristo <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
---
drivers/clk/ti/clk-814x.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
index e172920..9e85fcc 100644
--- a/drivers/clk/ti/clk-814x.c
+++ b/drivers/clk/ti/clk-814x.c
@@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
DT_CLK(NULL, "devosc_ck", "devosc_ck"),
DT_CLK(NULL, "mpu_ck", "mpu_ck"),
DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
+ DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
+ DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
+ DT_CLK(NULL, "timer1_fck", "timer1_fck"),
+ DT_CLK(NULL, "timer2_fck", "timer2_fck"),
DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
{ .node_name = NULL },
--
2.6.2
On dm814x we have some clocks at DPLLS and some at PRCM. Let's add a new
omap_prcm_init_data entry for the DPLLS so we can initalize timer clocks
early.
Cc: Paul Walmsley <[email protected]>
Cc: Tero Kristo <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/mach-omap2/prm_common.c | 6 ++++++
include/linux/clk/ti.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 3fc2cbe..55acc76 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -662,6 +662,11 @@ static struct omap_prcm_init_data am3_prm_data __initdata = {
.index = TI_CLKM_PRM,
.init = am33xx_prm_init,
};
+
+static struct omap_prcm_init_data dm814_pllss_data __initdata = {
+ .index = TI_CLKM_PLLSS,
+ .init = am33xx_prm_init,
+};
#endif
#ifdef CONFIG_ARCH_OMAP4
@@ -715,6 +720,7 @@ static const struct of_device_id const omap_prcm_dt_match_table[] __initconst =
#endif
#ifdef CONFIG_SOC_TI81XX
{ .compatible = "ti,dm814-prcm", .data = &am3_prm_data },
+ { .compatible = "ti,dm814-pllss", .data = &dm814_pllss_data },
{ .compatible = "ti,dm816-prcm", .data = &am3_prm_data },
#endif
#ifdef CONFIG_ARCH_OMAP2
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 223be69..57663c1 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -195,6 +195,7 @@ enum {
TI_CLKM_PRM,
TI_CLKM_SCRM,
TI_CLKM_CTRL,
+ TI_CLKM_PLLSS,
CLK_MAX_MEMMAPS
};
--
2.6.2
With the basic clocks now working we can enable GPIO.
Cc: Paul Walmsley <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index d5246b3..1b96cdf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -1230,8 +1230,6 @@ static struct omap_hwmod_ocp_if dm81xx_tptc3__alwon_l3_fast = {
/*
* REVISIT: Test and enable the following once clocks work:
- * dm81xx_l4_ls__gpio1
- * dm81xx_l4_ls__gpio2
* dm81xx_l4_ls__mailbox
* dm81xx_alwon_l3_slow__gpmc
* dm81xx_default_l3_slow__usbss
@@ -1250,6 +1248,8 @@ static struct omap_hwmod_ocp_if *dm814x_hwmod_ocp_ifs[] __initdata = {
&dm81xx_l4_ls__wd_timer1,
&dm81xx_l4_ls__i2c1,
&dm81xx_l4_ls__i2c2,
+ &dm81xx_l4_ls__gpio1,
+ &dm81xx_l4_ls__gpio2,
&dm81xx_l4_ls__elm,
&dm81xx_l4_ls__mcspi1,
&dm81xx_alwon_l3_fast__tpcc,
--
2.6.2
Looks like GPIO softreset status bit on both dm8168 and dm8148
is broken and only goes high initially. After writing to sysc
softreset bit, the resetdone bit never goes high again.
I noticed this as GPIOs are enabled from u-boot at least on t410.
And this can be tested easliy with the following commands in u-boot:
# mw.l 0x4818155c 0x2
# md.l 0x48032114 1
48032114: 00000001 ....
# mw.l 0x48032010 0x2
# md.l 0x48032114 1
48032114: 00000000 ....
Looks like the GPIO module is functional even with the resetdone
bit down.
Let's just tag the GPIOs for dm81xx with HWMOD_INIT_NO_RESET.
Cc: Paul Walmsley <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 1b96cdf..440fd6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -432,6 +432,7 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__elm = {
.user = OCP_USER_MPU,
};
+/* On dm81xx RESETDONE bit seems to never goes high again after SOFTRESET */
static struct omap_hwmod_class_sysconfig dm81xx_gpio_sysc = {
.rev_offs = 0x0000,
.sysc_offs = 0x0010,
@@ -463,6 +464,7 @@ static struct omap_hwmod dm81xx_gpio1_hwmod = {
.name = "gpio1",
.clkdm_name = "alwon_l3s_clkdm",
.class = &dm81xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
.main_clk = "sysclk6_ck",
.prcm = {
.omap4 = {
@@ -490,6 +492,7 @@ static struct omap_hwmod dm81xx_gpio2_hwmod = {
.clkdm_name = "alwon_l3s_clkdm",
.class = &dm81xx_gpio_hwmod_class,
.main_clk = "sysclk6_ck",
+ .flags = HWMOD_INIT_NO_RESET,
.prcm = {
.omap4 = {
.clkctrl_offs = DM81XX_CM_ALWON_GPIO_1_CLKCTRL,
--
2.6.2
We have never had dm814x booting properly with mainline kernel using
the legacy platform data based booting. Current minimal support is
device tree only.
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/mach-omap2/io.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3eaeaca..3c87e40 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -612,8 +612,7 @@ void __init ti814x_init_early(void)
ti814x_clockdomains_init();
dm814x_hwmod_init();
omap_hwmod_init_postsetup();
- if (of_have_populated_dt())
- omap_clk_soc_init = dm814x_dt_clk_init;
+ omap_clk_soc_init = dm814x_dt_clk_init;
}
void __init ti816x_init_early(void)
--
2.6.2
Otherwise drivers under pllss and prcm won't probe properly.
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/boot/dts/dm814x.dtsi | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 7988b42..5c8de19 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -215,7 +215,10 @@
prcm: prcm@180000 {
compatible = "ti,dm814-prcm", "simple-bus";
- reg = <0x180000 0x4000>;
+ reg = <0x180000 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x180000 0x2000>;
prcm_clocks: clocks {
#address-cells = <1>;
@@ -226,9 +229,13 @@
};
};
+ /* See TRM PLL_SUBSYS_BASE and "PLLSS Registers" */
pllss: pllss@1c5000 {
compatible = "ti,dm814-pllss", "simple-bus";
- reg = <0x1c5000 0x2000>;
+ reg = <0x1c5000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x1c5000 0x1000>;
pllss_clocks: clocks {
#address-cells = <1>;
--
2.6.2
Although we have hp t410 booting, I noticed that dm814x-evm does not boot
after I got one. This is because we don't have the clocks yet configured
properly. Let's start configuring proper clocks starting with the system
timers and clocks that work with existing mux and divider clock drivers.
Note that the oscillator speed register is different from am335x, dm814x
has only one bit that shows the BTMODE[6] at CONTROL_STATUS[21].
Also note that this only gets the system timers working with the defined
clocks. The PLL clocks are still missing and and the devices may or may
not work depending on what the bootloader has enabled.
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/boot/dts/dm814x-clocks.dtsi | 109 +++++++++++++++++++++++++----------
1 file changed, 79 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi b/arch/arm/boot/dts/dm814x-clocks.dtsi
index ef1e8e7..2600158 100644
--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
@@ -4,25 +4,74 @@
* published by the Free Software Foundation.
*/
+&pllss_clocks {
+ timer1_fck: timer1_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&sysclk18_ck &aud_clkin0_ck &aud_clkin1_ck
+ &aud_clkin2_ck &devosc_ck &auxosc_ck &tclkin_ck>;
+ ti,bit-shift = <3>;
+ reg = <0x2e0>;
+ };
+
+ timer2_fck: timer2_fck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&sysclk18_ck &aud_clkin0_ck &aud_clkin1_ck
+ &aud_clkin2_ck &devosc_ck &auxosc_ck &tclkin_ck>;
+ ti,bit-shift = <6>;
+ reg = <0x2e0>;
+ };
+
+ sysclk18_ck: sysclk18_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&rtcosc_ck>, <&rtcdivider_ck>;
+ ti,bit-shift = <0>;
+ reg = <0x02f0>;
+ };
+};
+
&scm_clocks {
+ devosc_ck: devosc_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&virt_20000000_ck>, <&virt_19200000_ck>;
+ ti,bit-shift = <21>;
+ reg = <0x0040>;
+ };
- tclkin_ck: tclkin_ck {
+ /* Optional auxosc, 20 - 30 MHz range, assume 27 MHz by default */
+ auxosc_ck: auxosc_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <27000000>;
+ };
+
+ /* Optional 32768Hz crystal or clock on RTCOSC pins */
+ rtcosc_ck: rtcosc_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
};
- devosc_ck: devosc_ck {
+ /* Optional external clock on TCLKIN pin, set rate in baord dts file */
+ tclkin_ck: tclkin_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ };
+
+ virt_20000000_ck: virt_20000000_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <20000000>;
};
- /* Optional auxosc, 20 - 30 MHz range, assume 27 MHz by default */
- auxosc_ck: auxosc_ck {
+ virt_19200000_ck: virt_19200000_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
- clock-frequency = <27000000>;
+ clock-frequency = <19200000>;
};
mpu_ck: mpu_ck {
@@ -49,12 +98,6 @@
clock-frequency = <48000000>;
};
- sysclk18_ck: sysclk18_ck {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <32768>;
- };
-
cpsw_125mhz_gclk: cpsw_125mhz_gclk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -69,7 +112,31 @@
};
-&pllss_clocks {
+&prcm_clocks {
+ osc_src_ck: osc_src_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&devosc_ck>;
+ clock-mult = <1>;
+ clock-div = <1>;
+ };
+
+ mpu_clksrc_ck: mpu_clksrc_ck {
+ #clock-cells = <0>;
+ compatible = "ti,mux-clock";
+ clocks = <&devosc_ck>, <&rtcdivider_ck>;
+ ti,bit-shift = <0>;
+ reg = <0x0040>;
+ };
+
+ /* Fixed divider clock 0.0016384 * devosc */
+ rtcdivider_ck: rtcdivider_ck {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&devosc_ck>;
+ clock-mult = <128>;
+ clock-div = <78125>;
+ };
aud_clkin0_ck: aud_clkin0_ck {
#clock-cells = <0>;
@@ -88,22 +155,4 @@
compatible = "fixed-clock";
clock-frequency = <20000000>;
};
-
- timer1_mux_ck: timer1_mux_ck {
- #clock-cells = <0>;
- compatible = "ti,mux-clock";
- clocks = <&sysclk18_ck &aud_clkin0_ck &aud_clkin1_ck
- &aud_clkin2_ck &devosc_ck &auxosc_ck &tclkin_ck>;
- ti,bit-shift = <3>;
- reg = <0x2e0>;
- };
-
- timer2_mux_ck: timer2_mux_ck {
- #clock-cells = <0>;
- compatible = "ti,mux-clock";
- clocks = <&sysclk18_ck &aud_clkin0_ck &aud_clkin1_ck
- &aud_clkin2_ck &devosc_ck &auxosc_ck &tclkin_ck>;
- ti,bit-shift = <6>;
- reg = <0x2e0>;
- };
};
--
2.6.2
The control module is at offset 0x14000 with size 0x20000, not 0x16000.
This causes the pinctrl driver to not work.
Let's also fix the comments related to the TRM "L4LS Instance Summary"
table as that's what's causing the bad entries.
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/boot/dts/dm814x.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 5c8de19..68b156b 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -58,8 +58,10 @@
ti,hwmods = "l3_main";
/*
- * See TRM "Table 1-317. L4LS Instance Summary", just deduct
- * 0x1000 from the 1-317 addresses to get the device address
+ * See TRM "Table 1-317. L4LS Instance Summary" for hints.
+ * It shows the module target agent registers though, so the
+ * actual device is typically 0x1000 before the target agent
+ * except in cases where the module is larger than 0x1000.
*/
l4ls: l4ls@48000000 {
compatible = "ti,dm814-l4ls", "simple-bus";
@@ -183,10 +185,10 @@
control: control@140000 {
compatible = "ti,dm814-scm", "simple-bus";
- reg = <0x140000 0x16d000>;
+ reg = <0x140000 0x20000>;
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0 0x160000 0x16d000>;
+ ranges = <0 0x140000 0x20000>;
scm_conf: scm_conf@0 {
compatible = "syscon";
--
2.6.2
Otherwise pinctrl won't work.
Signed-off-by: Tony Lindgren <[email protected]>
---
arch/arm/boot/dts/dm814x.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 68b156b..7bd1961 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -207,11 +207,11 @@
pincntl: pinmux@800 {
compatible = "pinctrl-single";
- reg = <0x800 0xc38>;
+ reg = <0x800 0x438>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x300ff>;
+ pinctrl-single,function-mask = <0x707ff>;
};
};
--
2.6.2
On 2 December 2015 at 00:38, Tony Lindgren <[email protected]> wrote:
> Looks like GPIO softreset status bit on both dm8168 and dm8148
> is broken and only goes high initially. After writing to sysc
> softreset bit, the resetdone bit never goes high again.
The resetdone bit works fine, but it needs all clocks active to come
up. You're neglecting to enable the debounce clock to the GPIO module:
> # mw.l 0x4818155c 0x2
That should write 0x102 instead.
You can disable the debounce clock after resetting the module if you
don't need it, though I doubt there's any significant power savings
there. (More likely it exists as a separate bit to allow it to stay
enabled even if the module isn't, for wakeup on debounced inputs.)
Matthijs
On 2 December 2015 at 00:38, Tony Lindgren <[email protected]> wrote:
> - pinctrl-single,function-mask = <0x300ff>;
> + pinctrl-single,function-mask = <0x707ff>;
Reminder that silicon revision 2.1 and older require input enabled
(bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage.
(Errata advisory 2.1.87)
* Matthijs van Duin <[email protected]> [151201 16:11]:
> On 2 December 2015 at 00:38, Tony Lindgren <[email protected]> wrote:
> > Looks like GPIO softreset status bit on both dm8168 and dm8148
> > is broken and only goes high initially. After writing to sysc
> > softreset bit, the resetdone bit never goes high again.
>
> The resetdone bit works fine, but it needs all clocks active to come
> up. You're neglecting to enable the debounce clock to the GPIO module:
>
> > # mw.l 0x4818155c 0x2
>
> That should write 0x102 instead.
It seems to work only once based on what I've seen :) If you try it
after it's powered it never works. Could be I'm doing something wrong
of course..
> You can disable the debounce clock after resetting the module if you
> don't need it, though I doubt there's any significant power savings
> there. (More likely it exists as a separate bit to allow it to stay
> enabled even if the module isn't, for wakeup on debounced inputs.)
Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we
have for many SoCs to enable also sysclk18_ck but no luck. I can
recheck that.
Regards,
Tony
* Matthijs van Duin <[email protected]> [151201 16:26]:
> On 2 December 2015 at 00:38, Tony Lindgren <[email protected]> wrote:
> > - pinctrl-single,function-mask = <0x300ff>;
> > + pinctrl-single,function-mask = <0x707ff>;
>
> Reminder that silicon revision 2.1 and older require input enabled
> (bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage.
> (Errata advisory 2.1.87)
Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
dts macros that ensure that?
Regards,
Tony
* Tony Lindgren <[email protected]> [151201 16:42]:
> * Matthijs van Duin <[email protected]> [151201 16:11]:
> > On 2 December 2015 at 00:38, Tony Lindgren <[email protected]> wrote:
> > > Looks like GPIO softreset status bit on both dm8168 and dm8148
> > > is broken and only goes high initially. After writing to sysc
> > > softreset bit, the resetdone bit never goes high again.
> >
> > The resetdone bit works fine, but it needs all clocks active to come
> > up. You're neglecting to enable the debounce clock to the GPIO module:
> >
> > > # mw.l 0x4818155c 0x2
> >
> > That should write 0x102 instead.
>
> It seems to work only once based on what I've seen :) If you try it
> after it's powered it never works. Could be I'm doing something wrong
> of course..
>
> > You can disable the debounce clock after resetting the module if you
> > don't need it, though I doubt there's any significant power savings
> > there. (More likely it exists as a separate bit to allow it to stay
> > enabled even if the module isn't, for wakeup on debounced inputs.)
>
> Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we
> have for many SoCs to enable also sysclk18_ck but no luck. I can
> recheck that.
You're right with 0x102 it works, need to debug further.
Thanks,
Tony
On 2 December 2015 at 01:46, Tony Lindgren <[email protected]> wrote:
> Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> dts macros that ensure that?
Can't we just keep bit 18 out of the function mask? The bootloader
should already have made sure all pins have bit 18 set (and bit 19 set
to correct values after ROM mucked them up, see advisory 2.1.88), so
all that needs to be done is avoid touching them.
Are the power savings from disabling unnecessary inputs significant
enough to spend any headache on it?
Matthijs
On 2 December 2015 at 01:46, Tony Lindgren <[email protected]> wrote:
> We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> dts macros that ensure that?
I'm in general no fan of such macros: it feels really awkward to have
to make that distinction in dts when doing pin config.
Note that if you're feeling really enthausiastic about putting in
effort to allow inputs to be disabled while staying clear of the
erratum, I think you can detect at runtime which I/O supplies are 3.3V
by inspecting this register:
#define CTRL_CQDETECT_STATUS 0x48140e00
Matthijs
* Matthijs van Duin <[email protected]> [151201 17:15]:
> On 2 December 2015 at 01:46, Tony Lindgren <[email protected]> wrote:
> > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > dts macros that ensure that?
>
> Can't we just keep bit 18 out of the function mask? The bootloader
> should already have made sure all pins have bit 18 set (and bit 19 set
> to correct values after ROM mucked them up, see advisory 2.1.88), so
> all that needs to be done is avoid touching them.
Sounds good to me. And people who really want to override the mask can
do it in the board specifc dts file.
> Are the power savings from disabling unnecessary inputs significant
> enough to spend any headache on it?
Only for some battery powered devices, not in this case for sure.
Regards,.
Tony
* Tony Lindgren <[email protected]> [151201 16:56]:
> * Tony Lindgren <[email protected]> [151201 16:42]:
> > * Matthijs van Duin <[email protected]> [151201 16:11]:
> > > On 2 December 2015 at 00:38, Tony Lindgren <[email protected]> wrote:
> > > > Looks like GPIO softreset status bit on both dm8168 and dm8148
> > > > is broken and only goes high initially. After writing to sysc
> > > > softreset bit, the resetdone bit never goes high again.
> > >
> > > The resetdone bit works fine, but it needs all clocks active to come
> > > up. You're neglecting to enable the debounce clock to the GPIO module:
> > >
> > > > # mw.l 0x4818155c 0x2
> > >
> > > That should write 0x102 instead.
> >
> > It seems to work only once based on what I've seen :) If you try it
> > after it's powered it never works. Could be I'm doing something wrong
> > of course..
> >
> > > You can disable the debounce clock after resetting the module if you
> > > don't need it, though I doubt there's any significant power savings
> > > there. (More likely it exists as a separate bit to allow it to stay
> > > enabled even if the module isn't, for wakeup on debounced inputs.)
> >
> > Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we
> > have for many SoCs to enable also sysclk18_ck but no luck. I can
> > recheck that.
>
> You're right with 0x102 it works, need to debug further.
Looks like also am33xx has opt clocks gate bit 18. Probably the best
way to deal with this in the long run is to set up the clkctrl and
optfclken as gate clocks with the clock framework. This is also needed
as we have some devices sharing a single clkctrl register.
Regards,
Tony
* Tony Lindgren <[email protected]> [151201 17:23]:
> * Matthijs van Duin <[email protected]> [151201 17:15]:
> > On 2 December 2015 at 01:46, Tony Lindgren <[email protected]> wrote:
> > > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > > dts macros that ensure that?
> >
> > Can't we just keep bit 18 out of the function mask? The bootloader
> > should already have made sure all pins have bit 18 set (and bit 19 set
> > to correct values after ROM mucked them up, see advisory 2.1.88), so
> > all that needs to be done is avoid touching them.
>
> Sounds good to me. And people who really want to override the mask can
> do it in the board specifc dts file.
>
> > Are the power savings from disabling unnecessary inputs significant
> > enough to spend any headache on it?
>
> Only for some battery powered devices, not in this case for sure.
And here's an updated version of this patch.
Regards,
Tony
8< ----------------------------
From: Tony Lindgren <[email protected]>
Date: Tue, 1 Dec 2015 15:04:38 -0800
Subject: [PATCH] ARM: dts: Fix dm814x pinctrl address and mask
Otherwise pinctrl won't work. Because of silicon errata for some dm814x
versions, let's also keep bit 18 out of the function-mask and rely on
the bootloader configuration for bit 18 as suggested by
Matthijs van Duin <[email protected]>.
Devices with that need to use bit 18 can override the function-mask in
the board specific dts file if really needed.
Signed-off-by: Tony Lindgren <[email protected]>
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -205,13 +205,21 @@
};
};
+ /*
+ * Note that silicon revision 2.1 and older
+ * require input enabled (bit 18 set) for all
+ * 3.3V I/Os to avoid cumulative hardware damage.
+ * For more info, see errata advisory 2.1.87.
+ * We leave bit 18 out of function-mask and rely
+ * on the bootloader for it.
+ */
pincntl: pinmux@800 {
compatible = "pinctrl-single";
- reg = <0x800 0xc38>;
+ reg = <0x800 0x438>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <32>;
- pinctrl-single,function-mask = <0x300ff>;
+ pinctrl-single,function-mask = <0x307ff>;
};
};
* Matthijs van Duin <[email protected]> [151201 17:23]:
> On 2 December 2015 at 01:46, Tony Lindgren <[email protected]> wrote:
> > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > dts macros that ensure that?
>
> I'm in general no fan of such macros: it feels really awkward to have
> to make that distinction in dts when doing pin config.
>
> Note that if you're feeling really enthausiastic about putting in
> effort to allow inputs to be disabled while staying clear of the
> erratum, I think you can detect at runtime which I/O supplies are 3.3V
> by inspecting this register:
>
> #define CTRL_CQDETECT_STATUS 0x48140e00
OK and if really needed needed the SoC revision information can be
passed to pinctrl-singl.c in it's platform_data that we already have
in addition to the dts configuration. And then pinctrl-single.c could
modify the mask based on IO voltage and SoC revision.
I think we're already covered as the boards can override the pinctrl
function-mask in the board specific dts file if really needed :)
Regards,
Tony
On 12/02/2015 01:38 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are some fixes for v4.5 merge window to get dm814x-evm booting.
> While hp t410 boots based on the bootloader clocks, dm814x-evm needs
> more things configured. Especially the clock dts entries were all
> wrong and just happened to be harmless on hp t410.
>
> To boot, you probably want to use v4.4-rc3 because of commit 29f5b34ca1a1
> ("arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data") and also
> manually apply commit 0db19b850468 ("net: cpsw: Fix ethernet regression
> for dm814x") from Linux next.
>
> I have more changes coming up after this series after I clean them
> up a bit. Here's a brief status update for people:
>
> What's working after this series on dm814x-evm and hp t410:
>
> - Timers
>
> - Serial
>
> - Ethernet
>
> - DMA
>
> - I2C (only tested so far with i2cdetect -r 0)
>
> - GPIO (only tested with additional MMC patches for card detect)
>
> I have the following additional patches coming soonish:
>
> - Basic ADPLL clock driver
>
> - MMC support
>
> - USB support
>
> - Minimal j5eco-evm support
>
> Should work with just configuration:
>
> - [PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers
>
> I'm not working on any of the accelerators or graphics FYI. If somebody
> has patches coming for those please notify on the linux-omap and
> linux-arm-kernel mailings lists so we can avoid duplicate work.
>
> Tony Lindgren (10):
> ARM: OMAP2+: Fix timer entries for dm814x
> clk: ti: Add few dm814x clock aliases
> ARM: OMAP2+: Add DPPLS clock manager for dm814x
> ARM: OMAP2+: Enable GPIO for dm814x
> ARM: OMAP2+: Disable GPIO softreset for dm81xx
> ARM: OMAP2+: Remove useless check for legacy booting for dm814x
> ARM: dts: Fix dm814x entries for pllss and prcm
> ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
> ARM: dts: Fix dm8148 control modules ranges
> ARM: dts: Fix dm814x pinctrl address and mask
I'm worry a bit, if you will apply this series in its current order
- it will break git bisect.
Patch one "ARM: OMAP2+: Fix timer entries for dm814x" will use timerX_fck, but those
clocks will be added by patches 2 "clk: ti: Add few dm814x clock aliases"
and 8 "ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting"
--
regards,
-grygorii
* Grygorii Strashko <[email protected]> [151203 10:18]:
> On 12/02/2015 01:38 AM, Tony Lindgren wrote:
>
> > Tony Lindgren (10):
> > ARM: OMAP2+: Fix timer entries for dm814x
> > clk: ti: Add few dm814x clock aliases
> > ARM: OMAP2+: Add DPPLS clock manager for dm814x
> > ARM: OMAP2+: Enable GPIO for dm814x
> > ARM: OMAP2+: Disable GPIO softreset for dm81xx
> > ARM: OMAP2+: Remove useless check for legacy booting for dm814x
> > ARM: dts: Fix dm814x entries for pllss and prcm
> > ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
> > ARM: dts: Fix dm8148 control modules ranges
> > ARM: dts: Fix dm814x pinctrl address and mask
>
> I'm worry a bit, if you will apply this series in its current order
> - it will break git bisect.
> Patch one "ARM: OMAP2+: Fix timer entries for dm814x" will use timerX_fck, but those
> clocks will be added by patches 2 "clk: ti: Add few dm814x clock aliases"
> and 8 "ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting"
Yeah you have a point there. I was hoping to separate them to dts and soc
related patches but clearly that's not possible.
We can keep t410 limping along just fine with this order:
ARM: dts: Fix dm814x entries for pllss and prcm
clk: ti: Add few dm814x clock aliases
ARM: OMAP2+: Add DPPLS clock manager for dm814x
ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
ARM: OMAP2+: Fix timer entries for dm814x
ARM: dts: Fix dm8148 control modules ranges
ARM: dts: Fix dm814x pinctrl address and mask
ARM: OMAP2+: Enable GPIO for dm814x
ARM: OMAP2+: Remove useless check for legacy booting for dm814x
Regards,
Tony
* Tony Lindgren <[email protected]> [151201 15:43]:
> The timer clock aliases are needed early on dm814x. Let's also
> add the aliases for the interconnects and MMC.
>
> Cc: Michael Turquette <[email protected]>
> Cc: Stephen Boyd <[email protected]>
> Cc: Tero Kristo <[email protected]>
> Signed-off-by: Tony Lindgren <[email protected]>
Anybody from the clock department care to ack this one? I'd like to
get this series into Linux next as it fixes some some issues.
Regards,
Tony
> drivers/clk/ti/clk-814x.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
> index e172920..9e85fcc 100644
> --- a/drivers/clk/ti/clk-814x.c
> +++ b/drivers/clk/ti/clk-814x.c
> @@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
> DT_CLK(NULL, "devosc_ck", "devosc_ck"),
> DT_CLK(NULL, "mpu_ck", "mpu_ck"),
> DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
> + DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
> DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
> + DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
> DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
> DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
> DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
> + DT_CLK(NULL, "timer1_fck", "timer1_fck"),
> + DT_CLK(NULL, "timer2_fck", "timer2_fck"),
> DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
> DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
> { .node_name = NULL },
> --
> 2.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> * Tony Lindgren <[email protected]> [151201 15:43]:
>> The timer clock aliases are needed early on dm814x. Let's also
>> add the aliases for the interconnects and MMC.
>>
>> Cc: Michael Turquette <[email protected]>
>> Cc: Stephen Boyd <[email protected]>
>> Cc: Tero Kristo <[email protected]>
>> Signed-off-by: Tony Lindgren <[email protected]>
>
> Anybody from the clock department care to ack this one?
Sorry been rather busy lately...
> I'd like to
> get this series into Linux next as it fixes some some issues.
Yeah looks good to me, don't have access to dm814x so can't test.
Acked-by: Tero Kristo <[email protected]>
Are you planning to push this via omap tree if this is critical for you?
-Tero
>
> Regards,
>
> Tony
>
>
>> drivers/clk/ti/clk-814x.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
>> index e172920..9e85fcc 100644
>> --- a/drivers/clk/ti/clk-814x.c
>> +++ b/drivers/clk/ti/clk-814x.c
>> @@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
>> DT_CLK(NULL, "devosc_ck", "devosc_ck"),
>> DT_CLK(NULL, "mpu_ck", "mpu_ck"),
>> DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
>> + DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
>> DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
>> + DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
>> DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
>> DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
>> DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
>> + DT_CLK(NULL, "timer1_fck", "timer1_fck"),
>> + DT_CLK(NULL, "timer2_fck", "timer2_fck"),
>> DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
>> DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
>> { .node_name = NULL },
>> --
>> 2.6.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tero Kristo <[email protected]> [151208 11:25]:
> On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >
> >Anybody from the clock department care to ack this one?
>
> Sorry been rather busy lately...
>
> >I'd like to
> >get this series into Linux next as it fixes some some issues.
>
> Yeah looks good to me, don't have access to dm814x so can't test.
>
> Acked-by: Tero Kristo <[email protected]>
Thanks.
> Are you planning to push this via omap tree if this is critical for you?
Yes this series needs to be merged in certain order to keep t410
booting. Should not conflict with anything else AFAIK.
Regards,
Tony
On 12/08/2015 10:11 PM, Tony Lindgren wrote:
> * Tero Kristo <[email protected]> [151208 11:25]:
>> On 12/08/2015 06:57 PM, Tony Lindgren wrote:
>>>
>>> Anybody from the clock department care to ack this one?
>>
>> Sorry been rather busy lately...
>>
>>> I'd like to
>>> get this series into Linux next as it fixes some some issues.
>>
>> Yeah looks good to me, don't have access to dm814x so can't test.
>>
>> Acked-by: Tero Kristo <[email protected]>
>
> Thanks.
>
>> Are you planning to push this via omap tree if this is critical for you?
>
> Yes this series needs to be merged in certain order to keep t410
> booting. Should not conflict with anything else AFAIK.
Ok at least I am fine with that. The dm81xx clock alias file is pretty
independent of anything else.
-Tero
* Tero Kristo <[email protected]> [151208 23:50]:
> On 12/08/2015 10:11 PM, Tony Lindgren wrote:
> >* Tero Kristo <[email protected]> [151208 11:25]:
> >>On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >>>
> >>>Anybody from the clock department care to ack this one?
> >>
> >>Sorry been rather busy lately...
> >>
> >>>I'd like to
> >>>get this series into Linux next as it fixes some some issues.
> >>
> >>Yeah looks good to me, don't have access to dm814x so can't test.
> >>
> >>Acked-by: Tero Kristo <[email protected]>
> >
> >Thanks.
> >
> >>Are you planning to push this via omap tree if this is critical for you?
> >
> >Yes this series needs to be merged in certain order to keep t410
> >booting. Should not conflict with anything else AFAIK.
>
> Ok at least I am fine with that. The dm81xx clock alias file is pretty
> independent of anything else.
Pushing this series except for the GPIO reset change into
omap-for-v4.5/81xx-fixes.
Regards,
Tony