From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:38:38
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
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:38:41
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 <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:38:44
The timer clock aliases are needed early on dm814x. Let's also
add the aliases for the interconnects and MMC.
Cc: Michael Turquette <redacted>
Cc: Stephen Boyd <redacted>
Cc: Tero Kristo <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/clk/ti/clk-814x.c | 4 ++++
1 file changed, 4 insertions(+)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:38:49
With the basic clocks now working we can enable GPIO.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:38:52
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 <paul@pwsan.com>
Cc: Tero Kristo <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/prm_common.c | 6 ++++++
include/linux/clk/ti.h | 1 +
2 files changed, 7 insertions(+)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:39:02
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 <tony@atomide.com>
---
arch/arm/mach-omap2/io.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:39:44
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 <tony@atomide.com>
---
arch/arm/boot/dts/dm814x.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:40:16
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 <tony@atomide.com>
---
arch/arm/boot/dts/dm814x-clocks.dtsi | 109 +++++++++++++++++++++++++----------
1 file changed, 79 insertions(+), 30 deletions(-)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-01 23:40:49
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 <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
1 file changed, 3 insertions(+)
@@ -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 */staticstructomap_hwmod_class_sysconfigdm81xx_gpio_sysc={.rev_offs=0x0000,.sysc_offs=0x0010,
From: Matthijs van Duin <hidden> Date: 2015-12-02 00:10:34
On 2 December 2015 at 00:38, Tony Lindgren [off-list ref] 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
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)
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-02 00:41:44
* Matthijs van Duin [off-list ref] [151201 16:11]:
On 2 December 2015 at 00:38, Tony Lindgren [off-list ref] wrote:
quoted
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:
quoted
# 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
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
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-02 00:54:39
* Tony Lindgren [off-list ref] [151201 16:42]:
* Matthijs van Duin [off-list ref] [151201 16:11]:
quoted
On 2 December 2015 at 00:38, Tony Lindgren [off-list ref] wrote:
quoted
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:
quoted
# 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..
quoted
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
From: Matthijs van Duin <hidden> Date: 2015-12-02 01:14:34
On 2 December 2015 at 01:46, Tony Lindgren [off-list ref] 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
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-02 01:22:09
* Matthijs van Duin [off-list ref] [151201 17:15]:
On 2 December 2015 at 01:46, Tony Lindgren [off-list ref] wrote:
quoted
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
From: Matthijs van Duin <hidden> Date: 2015-12-02 01:22:21
On 2 December 2015 at 01:46, Tony Lindgren [off-list ref] 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
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-02 01:38:14
* Tony Lindgren [off-list ref] [151201 16:56]:
* Tony Lindgren [off-list ref] [151201 16:42]:
quoted
* Matthijs van Duin [off-list ref] [151201 16:11]:
quoted
On 2 December 2015 at 00:38, Tony Lindgren [off-list ref] wrote:
quoted
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:
quoted
# 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..
quoted
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
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-02 16:10:06
* Tony Lindgren [off-list ref] [151201 17:23]:
* Matthijs van Duin [off-list ref] [151201 17:15]:
quoted
On 2 December 2015 at 01:46, Tony Lindgren [off-list ref] wrote:
quoted
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.
quoted
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 <tony@atomide.com>
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 [off-list ref].
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 <tony@atomide.com>
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-02 16:13:39
* Matthijs van Duin [off-list ref] [151201 17:23]:
On 2 December 2015 at 01:46, Tony Lindgren [off-list ref] wrote:
quoted
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
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
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
From: Tony Lindgren <tony@atomide.com> Date: 2015-12-08 16:57:39
* Tony Lindgren [off-list ref] [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 <redacted>
Cc: Stephen Boyd <redacted>
Cc: Tero Kristo <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
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
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Tero Kristo <hidden> Date: 2015-12-08 19:25:10
On 12/08/2015 06:57 PM, Tony Lindgren wrote:
* Tony Lindgren [off-list ref] [151201 15:43]:
quoted
The timer clock aliases are needed early on dm814x. Let's also
add the aliases for the interconnects and MMC.
Cc: Michael Turquette <redacted>
Cc: Stephen Boyd <redacted>
Cc: Tero Kristo <redacted>
Signed-off-by: Tony Lindgren <tony@atomide.com>
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 <redacted>
Are you planning to push this via omap tree if this is critical for you?
-Tero
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html