OMAP baseline test results for v4.0-rc5
Here are some basic OMAP test results for Linux v4.0-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc5/20150324122259/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 2420n800 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc4 (06e5801b8cb3fc057d88cb4dc03c0b64b2744cda)): text data bsstotal kernel -400 -4 omap1_defconfig -4 +320 +28 omap1_defconfig_1510innovator_only -4 +320 +28 omap1_defconfig_5912osk_only -576 -80 -584 multi_v7_defconfig -84 +640 -20 omap2plus_defconfig -12400 -124 omap2plus_defconfig_2430sdp_only -20 +640 +44 omap2plus_defconfig_am33xx_only -84 +640 -20 omap2plus_defconfig_am43xx_only -84 +640 -20
Re: [PATCH 2/2] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
On Mon, 16 Mar 2015, Suman Anna wrote:
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
This one results in compiler warnings:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c:1776:32: warning:
‘dra7xx_timer_secure_hwmod_class’ defined but not used [-Wunused-variable]
static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
Have queued the following for v4.1.
- Paul
From: Suman Anna s-a...@ti.com
Date: Mon, 16 Mar 2015 15:54:54 -0500
Subject: [PATCH] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
[p...@pwsan.com: dropped dra7xx_timer_secure_hwmod_class and
dra7xx_timer_secure_sysc to avoid compiler warnings]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d0f03e73add4..701234d8db1b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1763,21 +1763,6 @@ static struct omap_hwmod_class
dra7xx_timer_1ms_hwmod_class = {
.sysc = dra7xx_timer_1ms_sysc,
};
-static struct omap_hwmod_class_sysconfig dra7xx_timer_secure_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP),
- .sysc_fields= omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
- .name = timer,
- .sysc = dra7xx_timer_secure_sysc,
-};
-
static struct omap_hwmod_class_sysconfig dra7xx_timer_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1841,7 +1826,7 @@ static struct omap_hwmod dra7xx_timer3_hwmod = {
/* timer4 */
static struct omap_hwmod dra7xx_timer4_hwmod = {
.name = timer4,
- .class = dra7xx_timer_secure_hwmod_class,
+ .class = dra7xx_timer_hwmod_class,
.clkdm_name = l4per_clkdm,
.main_clk = timer4_gfclk_mux,
.prcm = {
--
2.1.4
Re: [PATCH 1/2] ARM: DRA7: hwmod: Add data for GPTimers 13 through 16
On Mon, 16 Mar 2015, Suman Anna wrote: Add the hwmod data for GPTimers 13, 14, 15 and 16. All these timers are present in the L4PER3 clock domain. The corresponding DT nodes are already present but disabled. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 96 +++ 1 file changed, 96 insertions(+) Thanks, queued for v4.1. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Couple of DRA7 hwmod patches on Timers
Hi Suman, On Mon, 16 Mar 2015, Suman Anna wrote: Following are couple of DRA7 hwmod patches for the GPTimers. Patches based on 4.0-rc1. The first patch adds the data for timers 13 through 16, the DT nodes are already present, and when enabled without the hwmod data triggers a l3_noc interrupt and hangs the kernel boot [1]. The boot hang can also be fixed by checking the return status of pm_runtime_get_sync() in the OMAP dmtimer probe, I will post a separate fix for that. Second patch is a minor fix. Thanks. Sounds like the first one should go in for v4.0-rc fixes, and the second one can wait for v4.1? If so then could you repost the first fix to include the description of why it should go in early in the patch description (the DT nodes are already present, and when enabled without the hwmod data triggers a l3_noc interrupt and hangs the kernel boot). That should avoid anyone questioning why it would go in as a v4.0-rc fix at this point, and should help the -stable crew out. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 19 Mar 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150319 08:46]: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? It seems it should be just a warning fix if the pciephy hwmod entries are now gone? Anyways, I'm planning to send a pull request for omap-for-v4.0/fixes today. Please let me know ASAP if the $subject patch should be dropped, otherwise I'll send it as it fixes a boot time warning and is already applied. If you want to send it up as a fix, that's fine with me. But I don't see how that second patch will cause any changes in device registration, as stated. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 05:45 PM, Paul Walmsley wrote: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? I've re-checked it - sorry for disinfo. PHY devices are created, but omap_device_fail_pm_domain is assigned to them. As result Runtime PM is not working any more. [0.592501] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' [0.597510] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124 [0.602794] ti-pipe3 4a094000.pciephy: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info When ti,hwmods is not present PCI PHY will be added as regular Platform device and Runtime PM will work again. OK then it should definitely go up as a fix. Kishon, for future references, those two patches should have been combined into a single patch. As it stands now, if someone bisects down to that first patch, it sounds like PM will be at least partially broken. Too bad I don't have a DRA7xx board where things like this can be tested before being sent upstream. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v4.0-rc4
Here are some basic OMAP test results for Linux v4.0-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc4/20150315232818/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc3 (9eccca0843205f87c00404b663188b88eb248051)): text data bsstotal kernel +377 +1280 +505 omap1_defconfig +377 +1040 +481 omap1_defconfig_1510innovator_only +377 +960 +473 omap1_defconfig_5912osk_only +1316 -104+1472+2684 multi_v7_defconfig -2948+40880+1140 omap2plus_defconfig +700 +320 +732 omap2plus_defconfig_2430sdp_only +1048 +6800+1728 omap2plus_defconfig_am33xx_only +1116 +7440+1860 omap2plus_defconfig_am43xx_only -2948+40320+1084
OMAP baseline test results for v4.0-rc3
Here are some basic OMAP test results for Linux v4.0-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc3/20150308193049/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc2 (13a7a6ac0a11197edcd0f756a035f472b42cdf8b)): text data bsstotal kernel +1521 +24 +64+1609 omap1_defconfig +1489 +16 +64+1569 omap1_defconfig_1510innovator_only +1521 +24 +64+1609 omap1_defconfig_5912osk_only +7910 -80 +64+7894 multi_v7_defconfig +1650 -8 +64+1706 omap2plus_defconfig +1546 -8 +64+1602 omap2plus_defconfig_2430sdp_only +1642 +32 +64+1738 omap2plus_defconfig_am33xx_only +1642 +24 +64+1730 omap2plus_defconfig_am43xx_only +1650 -8 +64+1706
Re: [PATCH 00/10] omap3 crypto fixes
On Sun, 8 Mar 2015, Pali Rohár wrote: On Friday 06 March 2015 23:23:06 Aaro Koskinen wrote: On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: Are there any fixes in this series that should go into v4.0-rc series, or can it all wait for v4.1? I think these all should wait for v4.1. A. I would suggest to include at least patches 01, 04, 06. Probably those could go to -stable tree... but this decision is up to you. I'm not sure patch 1 is a fix. As far as I know we haven't run into any issues with it on real hardware - only on QEMU - unless you know otherwise, Pali? Are we sure that the QEMU model behavior matches the hardware? - Paul
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
On Fri, 6 Mar 2015, Dave Gerlach wrote: On 03/06/2015 11:44 AM, Paul Walmsley wrote: On Fri, 6 Mar 2015, Dave Gerlach wrote: On 03/05/2015 10:26 PM, Paul Walmsley wrote: On Thu, 5 Mar 2015, Dave Gerlach wrote: RTC hwmod is needed for proper operation of PM features like rtcwake and rtc-only mode so reuse the am33xx rtc hwmod. Signed-off-by: Dave Gerlach d-gerl...@ti.com Thanks, queued for v4.1. Thanks, but please note as I just commented in Patch 1 of this series, without the ti,no-init flag in place that is introduced there this patch will cause the am43x-epos-evm to fail to boot. If that's so, shouldn't it appear in the series after patch 3, then? If only patches 1 and 2 are applied, then won't the boot be broken on am43x-epos-evm ? Hmm yes you are correct that would be the case, seems I should have swapped the order. I've gotten into the habit of putting dt patches last to enable what gets introduced previously, guess it's not always the best thing to do. Thanks for pointing this out. OK dropped until this thing is sorted out. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
Hi Dave,
On Fri, 6 Mar 2015, Dave Gerlach wrote:
Paul,
On 03/05/2015 10:26 PM, Paul Walmsley wrote:
On Thu, 5 Mar 2015, Dave Gerlach wrote:
RTC hwmod is needed for proper operation of PM features like
rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb8592..9070535 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if
*am43xx_hwmod_ocp_ifs[] __initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am33xx_l4_wkup__rtc,
NULL,
};
Thanks, queued for v4.1.
Thanks, but please note as I just commented in Patch 1 of this series, without
the ti,no-init flag in place that is introduced there this patch will cause
the
am43x-epos-evm to fail to boot.
If that's so, shouldn't it appear in the series after patch 3, then?
If only patches 1 and 2 are applied, then won't the boot be broken on
am43x-epos-evm ?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
On Thu, 5 Mar 2015, Dave Gerlach wrote: Introduce a dt property, ti,no-init, that prevents hwmod initialization. Even if a dt node is marked as disabled, hwmod still at least enables the hwmod and programs the sysconfig before attempting to idle it at boot. If an IP has been disabled by the hardware configuration on a platform, this will cause a hang due to writing to inactive registers. This property prevents that from happening by marking the hwmod as _HWMOD_STATE_DISABLED during init. I'm kind of wondering if hwmod should even touch a device if it's marked as disabled in the DT. Tony, what do you think? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP2+: AM43xx hwmod: Add RTC hwmod for AM43xx
On Thu, 5 Mar 2015, Dave Gerlach wrote:
RTC hwmod is needed for proper operation of PM features like
rtcwake and rtc-only mode so reuse the am33xx rtc hwmod.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb8592..9070535 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -889,6 +889,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am33xx_l4_wkup__rtc,
NULL,
};
Thanks, queued for v4.1.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v4.0-rc2
Here are some basic OMAP test results for Linux v4.0-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc2/20150303123351/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc1 (c517d838eb7d07bbe9507871fab3931deccff539)): text data bsstotal kernel +4 -80 -4 omap1_defconfig +6800 +68 omap1_defconfig_1510innovator_only +3600 +36 omap1_defconfig_5912osk_only +490589 +100104+7232 +597925 multi_v7_defconfig +15824 +5280 +16352 omap2plus_defconfig +6800 +68 omap2plus_defconfig_2430sdp_only +11728 +5600 +12288 omap2plus_defconfig_am33xx_only +15824 +5040 +16328 omap2plus_defconfig_am43xx_only +15824 +5360 +16360
Re: [PATCH v2 1/3] ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W
On Mon, 2 Mar 2015, Vignesh R wrote: From: Poddar, Sourav sourav.pod...@ti.com These adds hwmod data for hdq/1w driver on AM43xx. Signed-off-by: Vignesh R vigne...@ti.com --- Change log: v2: * Add SYSC_HAS_AUTOIDLE flag. arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36 ++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 37 insertions(+) Thanks, queued for v4.1. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: fix deassert hardreset clkdm usecounting
On Thu, 26 Feb 2015, Tero Kristo wrote: Deasserting hardreset increases the usecount for the hwmod parent clockdomain always, however usecount is only decreased at end in certain error cases. This causes software supervised clockdomains to remain always on, preventing idle. Fixed by always releasing the hwmods clockdomain parent when exiting the function. Signed-off-by: Tero Kristo t-kri...@ti.com Tested-by: Carlos Hernandez c...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Thanks, queued for v4.0-rc fixes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen
On Fri, 27 Feb 2015, Tero Kristo wrote: This was incorrectly reading the irq status registers during the save and clear, instead of the irq enable. This worked because there is only one user for the prcm interrupts currently, namely the io-chain. Whenever the function was called, an io-chain interrupt was both pending and enabled. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Thanks queued for v4.0-rc fixes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W
Hi
On Fri, 27 Feb 2015, Vignesh R wrote:
From: Poddar, Sourav sourav.pod...@ti.com
This patch adds hwmod data for hdq/1w driver on AM43xx.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[vigne...@ti.com: Ported patch to v4.0-rc1]
Signed-off-by: Vignesh R vigne...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36
++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 8eb85925e444..d4f1df28475c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -20,6 +20,7 @@
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
#include omap_hwmod_common_data.h
+#include hdq1w.h
/* IP blocks */
@@ -516,6 +517,33 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
.parent_hwmod = am43xx_dss_core_hwmod,
};
+/* HDQ1W */
+static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0014,
+ .syss_offs = 0x0018,
+ .sysc_flags = (SYSC_HAS_SOFTRESET),
This is missing the SYSC_HAS_AUTOIDLE bit. Is this intentional?
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
+ .name = hdq1w,
+ .sysc = am43xx_hdq1w_sysc,
+ .reset = omap_hdq1w_reset,
+};
+
+static struct omap_hwmod am43xx_hdq1w_hwmod = {
+ .name = hdq1w,
+ .class = am43xx_hdq1w_hwmod_class,
+ .clkdm_name = l4ls_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -790,6 +818,13 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l4_ls__hdq1w = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_hdq1w_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -889,6 +924,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l4_ls__hdq1w,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..48df3b55057e 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -143,5 +143,6 @@
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET 0x05C0
#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
+#define AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET 0x04a0
#endif
--
1.9.1
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: first set of hwmod and PRCM fixes for v4.0-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.0-rc/omap-fixes-a for you to fetch changes up to 50f59d07e9822274a2e6034777eb4e90cfb30cfc: ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen (2015-03-01 16:58:25 -0700) - ARM: OMAP2+: first set of hwmod and PRCM fixes for v4.0-rc This series fixes the following bugs: - - a lockdep problem with the OMAP hwmod code; - - incorrect PCIe hwmod data for the DRA7xx chips; - - the clockdomain handling in the hardreset deassertion code, preventing idle; - - the use of an IRQ status register rather than an IRQ enable register in the OMAP4 PRM code. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/test_v4.0-rc1/2015022439/ - Kishon Vijay Abraham I (1): ARM: DRA7: hwmod_data: Fix hwmod data for pcie Peter Ujfalusi (1): ARM: omap2+: omap_hwmod: Set unique lock_class_key per hwmod Tero Kristo (2): ARM: OMAP2+: hwmod: fix deassert hardreset clkdm usecounting ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen arch/arm/mach-omap2/omap_hwmod.c | 10 +-- arch/arm/mach-omap2/omap_hwmod.h | 1 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 103 +++--- arch/arm/mach-omap2/prm44xx.c | 4 +- 4 files changed, 32 insertions(+), 86 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8+CLAAoJEMePsQ0LvSpLU3cP/3NYx5iygsZvXczKIKC2Lejr 9uYmogLZ1fP8In/GDMjTSffd2DeO9/e0tdvaDShdbMKjREzVqLFfepsEWPSgYeFx V22Vyi3NH+EtUjQYoB0ZpyK2PuymsIYIAOJi4eR18rhbT3ajvQwOKn9U8zdRxNZ8 9msG1MzWrbWNX32wlYatKF8n9girzYy0yZ2s96mXDphQ9/WvgIOHQKZM9IU61xQ7 KKkX+lV+dXtyhl9NzBngTRuJ5U6xRfiUir8z+LEPQ6KwGwKMiKFVieN+eIX52tLN WpIj0sTY6TlBvSzTFVXUilMLd4Rq+3MF0U80xU/lZlGW3IVXo5fMCQT7Nag7LyXj N8NlRNvK9dR31BjjJmPqKylPZFe/wgQ2wiFXiwdCYu8PzHzKOcNGOwzN6hOe9bhY NUoG44gX5/89F9MWWbj42n8HtOHHoXpoup7kbuhLgoUPbOfIggmseFgWMOLApWq0 nTWaUHSaS5s1GCEM8GONQsCHUnPmxEBGiLs3xwB0f1kVqzBK3LyB315NSJATNEC4 nUmVBr6AqVAH3fhPsa8LjcraIa/FVDEWTHKSVEoLjvyl0k7yoxLYatlCqX9Yssni ydx+hkuVwRxo6KoYPkOuj63ps/dQ5i5P07iVxAGE6GGmh3PGewn+lhmdA9cqTtjV xf2lNp2+8Xfdl1Ooc3ke =S6Da -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: DRA7: hwmod_data: Fix hwmod data for pcie
On Fri, 20 Feb 2015, Kishon Vijay Abraham I wrote: Fixed hwmod data for pcie by having the correct module mode offset. Previously this module mode offset was part of pcie PHY which was wrong. Now this module mode offset was moved to pcie hwmod and removed the hwmod data for pcie phy. While at that renamed pcie_hwmod to pciess_hwmod in order to match with the name given in TRM. This helps to get rid of the following warning omap_hwmod: pcie1: _wait_target_disable failed [grygorii.stras...@linaro.org: Found the issue that actually caused omap_hwmod: pcie1: _wait_target_disable failed] Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Thanks sent this for v4.0-rc fixes. Unfortunately I don't have a DRA7xx board so can't test. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: first set of hwmod and PRCM fixes for v4.0-rc
On Mon, 2 Mar 2015, Paul Walmsley wrote: Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/test_v4.0-rc1/2015022439/ Just noticed that I put the wrong URL in the tag. Will fix and send and updated request. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL v2] ARM: OMAP2+: first set of hwmod and PRCM fixes for v4.0-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.0-rc/omap-fixes-a for you to fetch changes up to 50f59d07e9822274a2e6034777eb4e90cfb30cfc: ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen (2015-03-01 16:58:25 -0700) - ARM: OMAP2+: first set of hwmod and PRCM fixes for v4.0-rc This series fixes the following bugs: - - a lockdep problem with the OMAP hwmod code; - - incorrect PCIe hwmod data for the DRA7xx chips; - - the clockdomain handling in the hardreset deassertion code, preventing idle; - - the use of an IRQ status register rather than an IRQ enable register in the OMAP4 PRM code. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v4.0-rc/20150301165949/ - Kishon Vijay Abraham I (1): ARM: DRA7: hwmod_data: Fix hwmod data for pcie Peter Ujfalusi (1): ARM: omap2+: omap_hwmod: Set unique lock_class_key per hwmod Tero Kristo (2): ARM: OMAP2+: hwmod: fix deassert hardreset clkdm usecounting ARM: OMAP4+: PRM: fix omap4 version of prm_save_and_clear_irqen arch/arm/mach-omap2/omap_hwmod.c | 10 +-- arch/arm/mach-omap2/omap_hwmod.h | 1 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 103 +++--- arch/arm/mach-omap2/prm44xx.c | 4 +- 4 files changed, 32 insertions(+), 86 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8+NdAAoJEMePsQ0LvSpLWAsQAIFPj9Ha4r8T78q1s/Q57HZI uygJxhWN2j1//z4F17Ya+Ig1MAJryBILDUitvC4IhkeWgKS5Y3TNLfYmnYiSxuJT pzpgnmnuF7AY2tUtQkxuxbg2JDjNFB4EAWolbEDRYlYl5dzCy+UP4uJfXl5UBRRO D461ZhgBzTuLcQADePMDld2o62BDZ4GQT9ItGmcnlN+oujasLbRR68EAoLLHpo1i sGYVlMSzduaZe+dN1SNty4QKJoI1BI9PTQ5jVCpHZGuJ0JkS94Y7ir34yDQ6Er5G bjan1Qv5oA2v6TmwxNAD5gcH/D+TIsemlp5uF4PANJdwLyDMNsVxI6FLxonfaCTD +f5rn0u8C+xAiX8X71XonYBWvglfn5csXuPD8O8RgoohnuXNF2y957sHANp6PwWT KLd9YCKpNzQJsy/TswlbNrOHUrkMXbO9fbA/XAsYgH7wXPmDr+55EhB5jSJZwhmU A0Ab4BMJqPQQwQIgzWn4Mz6ZVaDgxBRD9DIiOl+41ZiOYFS/URC0Mnx1ofMjvY5H pBakVSQc9IF2OmGWRjO2eEygzL2EpHGwUEaIjIWg8oy7fkZ4eZfKZ2yRfW/kshp9 McYUngoNtYInVLULIsQ148HCWel7jpSCJO/kLq9L7cMcW/e6GjddbRyMEiAP19CF j1ePWtyWAWZrtwMbyOai =92Qe -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v4.0-rc1
Here are some basic OMAP test results for Linux v4.0-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc1/2015022439/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v3.19 (bfa76d49576599a4b9f9b7a71f23d73d6dcff735)): text data bsstotal kernel +40745 -29616 +760 +11889 omap1_defconfig +40745 -29592 +760 +11913 omap1_defconfig_1510innovator_only +40753 -29528 +760 +11985 omap1_defconfig_5912osk_only +252200 -28128+1408 +225480 multi_v7_defconfig -425693 -87568-2624 -515885 omap2plus_defconfig -421694 -58912-2624 -483230 omap2plus_defconfig_2430sdp_only -441053 -61872-2432 -505357 omap2plus_defconfig_am33xx_only -428201 -62840-2432 -493473 omap2plus_defconfig_am43xx_only -425693 -87568-2624 -515885
Re: [PATCH] ARM: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
On Fri, 13 Feb 2015, grygorii.stras...@linaro.org wrote: On 02/12/2015 11:08 PM, Paul Walmsley wrote: Thanks guys. On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote: Looks good for me and seems working. Grygorii, can I add your Acked-by? - Paul There is my Signed-off-by :) OK thanks, queued for v3.20-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
Thanks guys. On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote: Looks good for me and seems working. Grygorii, can I add your Acked-by? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
+ Felipe, Nishanth Hi Lokesh, what's the status here? - Paul On Fri, 2 Jan 2015, Paul Walmsley wrote: Ping. Are you going to redo this one? - Paul On Wed, 26 Nov 2014, Paul Walmsley wrote: Hi Lokesh On Tue, 25 Nov 2014, Lokesh Vutla wrote: Hi Paul, On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: On Thu, 20 Nov 2014, Lokesh Vutla wrote: On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: RTC IP have kicker feature which prevents spurious writes to its registers. In order to write into any of the RTC registers, KICK values has te be written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc sysconfig register without writing into any kick register which is a noop. When autoidle is allowed for rtc, interruts are not received until IDLEMODE is set to SIDLE_SMART_WKUP. Adding a reset function to unlock RTC registers so that IDLEMODE is updated. Ping..!! Is this patch acceptable? Lokesh 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, or against v3.19? If so it would be very helpful for the maintainers if you were to state that somewhere. Yes. This is a fix, intended to go in 3.18-rc. Sorry should have mentioned it. A few questions. Do you know when this problem started (in terms of kernel versions)? Also: the patch description states that this is only a problem when autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS driver? Or does hwmod wind up doing this after the RTCSS driver unlocks it? 2. Your patch unlocks the RTC registers, but never relocks it. This seems to defeat the point of the spurious write protection. Shouldn't your patch only unlock the RTC immediately before the hwmod code touches the RTC registers, and then relock it immediately afterwards, per SPRUHZ6 section 23.4.3.3? If so then the .reset function pointer is the wrong place for this; I would suggest adding some .lock and .unlock function pointers that are to be called before and after any register write to the IP block. Yeah I agree with you. Currently rtc driver unlocks these kick registers in probe and leaves it unlocks for further use. But if hwmod does unlock and lock for every sysconfig write driver should also implement unlock and lock for every rtc register write, which adds an extra overhead. I am not sure if some one writes into rtc registers other than hwmod and driver. IMO we can leave it unlocked as the driver does. I would think that the best approach would be to set up .lock and .unlock function pointers, then add a temporary hwmod flag that, if set, would prevent the .lock function from ever being called. Then once the driver is fixed, that flag can be dropped. 3. Your macros don't mention DRA7xx specifically. Does this sequence apply to some other TI chips, or just DRA7xx? Please document this in a comment above the macros, and possibly change the name of the macros to refer to DRA7XX. This sequence applies to AM43xx and AM33xx also. So made it generic. Ill document it. OK but it would need more than just documentation, right? Wouldn't the hwmod data also need to be modified for AM33xx/AM43xx to add the .reset function pointer? Any reason why folks wouldn't have seen this problem on AM33xx/AM43xx? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dra7xx: hwmod: drop .modulemode from pcie1/2 hwmods
On Thu, 12 Feb 2015, Paul Walmsley wrote:
On Fri, 13 Feb 2015, grygorii.stras...@linaro.org wrote:
On 02/12/2015 11:08 PM, Paul Walmsley wrote:
Thanks guys.
On Thu, 12 Feb 2015, grygorii.stras...@linaro.org wrote:
Looks good for me and seems working.
Grygorii, can I add your Acked-by?
- Paul
There is my Signed-off-by :)
OK thanks, queued for v3.20-rc.
Actually, could you guys test the updated patch? It had to be changed to
apply on mainline and I don't have a DRA7xx board to test.
- Paul
From 0f9a1ee083a7adbb2c867d5c8d25d7e5fcb38b07 Mon Sep 17 00:00:00 2001
From: Kishon Vijay Abraham I kis...@ti.com
Date: Thu, 12 Feb 2015 09:29:31 -0700
Subject: [PATCH] ARM: DRA7: hwmod_data: Fix hwmod data for pcie
Fixed hwmod data for pcie by having the correct module mode offset.
Previously this module mode offset was part of pcie PHY which was wrong.
Now this module mode offset was moved to pcie hwmod and removed the
hwmod data
for pcie phy. While at that renamed pcie_hwmod to pciess_hwmod in order
to match with the name given in TRM.
This helps to get rid of the following warning
omap_hwmod: pcie1: _wait_target_disable failed
[grygorii.stras...@linaro.org: Found the issue that actually caused
omap_hwmod: pcie1: _wait_target_disable failed]
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
[p...@pwsan.com: updated to apply on mainline]
---
arch/arm/boot/dts/dra7.dtsi | 2 -
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 111 ++
2 files changed, 35 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fedafd43..18a904db32bb 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -,7 +,6 @@
wkupclk, refclk,
div-clk, phy-div;
#phy-cells = 0;
- ti,hwmods = pcie1-phy;
};
pcie2_phy: pciephy@4a095000 {
@@ -1130,7 +1129,6 @@
wkupclk, refclk,
div-clk, phy-div;
#phy-cells = 0;
- ti,hwmods = pcie2-phy;
status = disabled;
};
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..6a74a7ea8c95 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1466,29 +1466,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
*
*/
-static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
.name = pcie,
};
/* pcie1 */
-static struct omap_hwmod dra7xx_pcie1_hwmod = {
+static struct omap_hwmod_rst_info dra7xx_pciess1_resets[] = {
+ { .name = pcie, .rst_shift = 0 },
+};
+
+static struct omap_hwmod dra7xx_pciess1_hwmod = {
.name = pcie1,
- .class = dra7xx_pcie_hwmod_class,
+ .class = dra7xx_pciess_hwmod_class,
.clkdm_name = pcie_clkdm,
.main_clk = l4_root_clk_div,
+ .rst_lines = dra7xx_pciess1_resets,
+ .rst_lines_cnt = ARRAY_SIZE(dra7xx_pciess1_resets),
.prcm = {
.omap4 = {
- .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
};
/* pcie2 */
-static struct omap_hwmod dra7xx_pcie2_hwmod = {
+
+static struct omap_hwmod_rst_info dra7xx_pciess2_resets[] = {
+ { .name = pcie, .rst_shift = 1 },
+};
+
+static struct omap_hwmod dra7xx_pciess2_hwmod = {
.name = pcie2,
- .class = dra7xx_pcie_hwmod_class,
+ .class = dra7xx_pciess_hwmod_class,
.clkdm_name = pcie_clkdm,
+ .rst_lines = dra7xx_pciess2_resets,
+ .rst_lines_cnt = ARRAY_SIZE(dra7xx_pciess2_resets),
.main_clk = l4_root_clk_div,
.prcm = {
.omap4 = {
@@ -1498,44 +1512,7 @@ static struct omap_hwmod dra7xx_pcie2_hwmod = {
},
};
-/*
- * 'PCIE PHY' class
- *
- */
-static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
- .name = pcie-phy,
-};
-
-/* pcie1 phy */
-static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
- .name = pcie1-phy,
- .class = dra7xx_pcie_phy_hwmod_class,
- .clkdm_name = l3init_clkdm,
- .main_clk
Re: [PATCH] ARM: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
On Wed, 11 Feb 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150210 18:28]: On Tue, 10 Feb 2015, Jon Hunter wrote: On 07/02/2015 00:23, Paul Walmsley wrote: Unfortunately, there is not a single TRM for the omap5910 but individual documents for each chapter in the original TRM. Check out the OMAP5910 Dual-Core Processor Timer Reference Guide and possibly the OMAP5910 Dual-Core Processor Clock Generation and System Reset Management Reference Guide The omap15xx/5910 did have a 32k timer but as you can see it appears it was never supported by the kernel for this device (not sure why). I do recall that there is some errata regarding the 32k timer, if you look at the omap5910 errata document and search for 32k you should find it. OK thanks for the context. I probably am not going to investigate adding support for this timer on OMAP1510/5910 - am primarily trying to avoid causing a regression on the existing platforms. At least I've never seen the 32KiHz timer registers in any 15xx documentation. Jon are you sure you're not mixing up 5910 (15xx) and 5912 (16xx)? It's documented in the OMAP5910 Timer Reference Guide (SPRU682A) Section 3 32-kHz Timer, at the link Jon mentioned. Have not checked the errata that Jon mentioned though. Regarding the patch: I'd suggest keeping the compilation warning fixes (which was the original purpose of the patch) from anything that changes the logic too much. That way if there's an error in the patch that changes the logic and it needs to be reverted, it won't also revert the warning fixes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
Hi John,
thanks for the review,
On Tue, 10 Feb 2015, Jon Hunter wrote:
On 07/02/2015 00:23, Paul Walmsley wrote:
Building an OMAP1510-only Kconfig generates the following warnings:
arch/arm/mach-omap1/pm.c: In function ‘omap1_pm_idle’:
arch/arm/mach-omap1/pm.c:123:2: warning: #warning Enable 32kHz OS timer
in order to allow sleep states in idle [-Wcpp]
#warning Enable 32kHz OS timer in order to allow sleep states in idle
^
arch/arm/mach-omap1/pm.c: At top level:
arch/arm/mach-omap1/pm.c:76:23: warning: ‘enable_dyn_sleep’ defined but
not used [-Wunused-variable]
static unsigned short enable_dyn_sleep = 0;
^
These are not so easy to fix in an obviously correct fashion, since I
don't have these devices up and running in my testbed. So, use
arch/arm/plat-omap/Kconfig and the existing pm.c source as a guide,
and posit that deep power saving states are only supported on OMAP16xx
chips with kernels built with both CONFIG_OMAP_DM_TIMER=y and
CONFIG_OMAP_32K_TIMER=y.
While here, clean up a few printk()s and unnecessary #ifdefs.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jon Hunter jonath...@nvidia.com
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Tuukka Tikkanen tuukka.tikka...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
Hi folks, if anyone out there is still experimenting with OMAP1 PM, or has
a copy of the OMAP1510 TRMs, could you please check this patch? I'm
unable to test it since I don't have any OMAP1 devices currently active
in the testbed. It at least compiles and deals with the build warnings:
You can find the omap5910 documents here [1]. The omap5910 is equivalent
to the omap1510.
OK good to be reminded of that :-)
Unfortunately, there is not a single TRM for the omap5910 but individual
documents for each chapter in the original TRM. Check out the OMAP5910
Dual-Core Processor Timer Reference Guide and possibly the OMAP5910
Dual-Core Processor Clock Generation and System Reset Management
Reference Guide
The omap15xx/5910 did have a 32k timer but as you can see it appears it
was never supported by the kernel for this device (not sure why). I do
recall that there is some errata regarding the 32k timer, if you look at
the omap5910 errata document and search for 32k you should find it.
OK thanks for the context. I probably am not going to investigate adding
support for this timer on OMAP1510/5910 - am primarily trying to avoid
causing a regression on the existing platforms.
I no longer have access to omap15xx h/w to test. However, I do have
omap5912 if you want me to test.
Only if you feel like it! Am fine with just having the review.
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Non-critical; targeted for v3.20-rc1 or v3.21-rc1.
arch/arm/mach-omap1/pm.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 34b4c0044961..d46d8a222fbb 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,13 +71,7 @@ static unsigned int
mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifndef CONFIG_OMAP_32K_TIMER
-
-static unsigned short enable_dyn_sleep = 0;
-
-#else
-
-static unsigned short enable_dyn_sleep = 1;
+static unsigned short enable_dyn_sleep;
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
@@ -90,8 +84,9 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
{
unsigned short value;
if (sscanf(buf, %hu, value) != 1 ||
- (value != 0 value != 1)) {
- printk(KERN_ERR idle_sleep_store: Invalid value\n);
+ (value != 0 value != 1) ||
+ (value != 0 !IS_ENABLED(CONFIG_OMAP_32K_TIMER))) {
+ pr_err(idle_sleep_store: Invalid value\n);
return -EINVAL;
}
enable_dyn_sleep = value;
@@ -101,7 +96,6 @@ static ssize_t idle_store(struct kobject *kobj,
struct kobj_attribute *attr,
static struct kobj_attribute sleep_while_idle_attr =
__ATTR(sleep_while_idle, 0644, idle_show, idle_store);
-#endif
static void (*omap_sram_suspend)(unsigned long r0, unsigned long r1) =
NULL;
@@ -120,12 +114,11 @@ void omap1_pm_idle(void)
local_fiq_disable();
#if defined(CONFIG_OMAP_MPU_TIMER) !defined(CONFIG_OMAP_DM_TIMER)
-#warning Enable 32kHz OS timer in order to allow sleep states in idle
use_idlect1 = use_idlect1 ~(1 9
Re: [PATCHv2] ARM: omap2+: omap_hwmod: Set unique lock_class_key per hwmod
On Tue, 10 Feb 2015, Peter Ujfalusi wrote: Add struct lock_class_key to omap_hwmod struct and use it to set unique lockdep class per hwmod. This will ensure that lockdep will know that each omap_hwmod-_lock should be treated as separate class and will not give false warning about deadlock or other issues due to nested use of hwmods. DRA7x's ATL hwmod is one example for this since McASP can select ATL clock as functional clock, which will trigger nested oh-_lock usage. This will trigger false warning from lockdep validator as it is dealing with classes and for it all hwmod clocks are the same class. Suggested-by: Peter Zijlstra pet...@infradead.org Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Thanks queued for v3.20-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Hi Felipe On Tue, 27 Jan 2015, Paul Walmsley wrote: On Tue, 27 Jan 2015, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 05:12:05PM +, Paul Walmsley wrote: On Tue, 27 Jan 2015, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). Just checking on this. Heard anything from the hardware team? If not I'd say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: AM43xx: hwmod: add VPFE hwmod entries
On Wed, 28 Jan 2015, Benoit Parrot wrote: Suspend/resume is functional with this patch. Tested-by: Benoit Parrot bpar...@ti.com Thanks folks, queued for v3.21. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
On Tue, 10 Feb 2015, Felipe Balbi wrote: On Tue, Feb 10, 2015 at 11:12:40PM +, Paul Walmsley wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). Just checking on this. Heard anything from the hardware team? If not I'd say the HWMOD_CANNOT_DISABLE approach is probably the right one for now... nothing from HW team yet. Last I heard is that they can reproduce the issue, and are now digging through documentation (and maybe RTL, but I'm speculating) to see if that should be supported or not. From my point of view, however, the thing idles, it just doesn't report it. Ok sounds like the thing to do is to wait until you hear back from them, if they are still looking at it. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.19
Here are some basic OMAP test results for Linux v3.19. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19/20150208213625/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 3/20): omap1_defconfig, omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v3.19-rc7 (e36f014edff70fc02b3d3d79cead1d58f289332e)): text data bsstotal kernel +166 -6800 -514 omap1_defconfig +134 -6480 -514 omap1_defconfig_1510innovator_only +134 -680 -32 -578 omap1_defconfig_5912osk_only +1102 -5680 +534 multi_v7_defconfig +1030 -8960 +134 omap2plus_defconfig +686 -8320 -146 omap2plus_defconfig_2430sdp_only +1030 -8320 +198 omap2plus_defconfig_am33xx_only +970 -8960 +74 omap2plus_defconfig_am43xx_only +1030 -8960 +134 omap2plus_defconfig_cpupm +1098 -8960 +202 omap2plus_defconfig_dra7xx_only +37200 +372 omap2plus_defconfig_n800_multi_omap2xxx +34000 +340 omap2plus_defconfig_n800_only_a +1034 -8960 +138 omap2plus_defconfig_no_pm +970 -8960 +74 omap2plus_defconfig_omap2_4_only +1034 -8960 +138 omap2plus_defconfig_omap3_4_only +5130 -8960+4234 omap2plus_defconfig_omap5_only +3400 +16 +356 rmk_omap3430_ldp_allnoconfig +230 -7760 -546 rmk_omap3430_ldp_oldconfig +364
Re: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
On Mon, 9 Feb 2015, Peter Ujfalusi wrote:
On 02/06/2015 09:26 PM, Peter Ujfalusi wrote:
Yeah, I've never really bothered with data too much, its a debug
feature. So lock_class_key is 8 bytes, and strictly speaking you could
union them over other fields, all we really need is unique addresses, we
don't actually use the storage.
True. our omap2plus defconfig does not have LOCKDEP enabled so it should not
add anything to the data when running default kernel.
I'll test the lockdep_set_class() method you suggested on Monday (not
tomorrow), but still as first thing.
If it is working as expected I'll send a patch with you as author.
With omap2plus_defconfig my build produces (vmlinux size):
Base: 99905522
with my series: 99908385 (base + 2863)
with Peter Zijlstra's patch: 99910625 (base + 5103)
The reason for this is that we will only have
struct lock_class_key { };
in case of !CONFIG_LOCKDEP. On ARM however CONFIG_LOCKDEP is enabled by
default, while the CONFIG_DEBUG_LOCKDEP is disabled.
So it does add more data to our default omap2plus config.
Tony: do you have preference on the way we fix this issue?
As I recall there is a plan to remove the hwmod static database and move it or
generate it from DT? Not sure when and how this will be done, but will it
affect the lockdep_set_class() way?
Well I guess we could see what Tony says, but you do realize that the
difference in sizes that you posted above is about .003% of the total
binary size, right?
If there's one thing we can say about the last few years of ARM kernel
development, it's that those kind of size increases are utterly dwarfed by
other changes in the kernel. So I'd say, post a patch based on PeterZ's
fix and be done with it...
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: ti-soc-thermal: fix compilation warnings when !CONFIG_PM_SLEEP
On Mon, 9 Feb 2015, Nishanth Menon wrote:
On 00:17-20150207, Paul Walmsley wrote:
When CONFIG_PM_SLEEP=n, the following compilation warnings appear:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
‘ti_bandgap_suspend’ defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
‘ti_bandgap_resume’ defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
A few years ago, suspend/resume-related code was protected by CONFIG_PM.
But that was changed and now it's protected by CONFIG_PM_SLEEP. Fix the
warnings by converting the preprocessor test in the TI bandgap thermal
sensor driver from testing CONFIG_PM to testing CONFIG_PM_SLEEP.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
Non-critical. Targeted for either v3.20-rc1 or v3.21-rc1.
Basic test reports for a series that includes this patch (and a few other
unrelated warning cleanups) is available here:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Compare to:
http://www.pwsan.com/omap/testlogs/test_v3.19-rc7/20150204213018/
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce0e63a..62a5d449c388 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
2.1.4
I am a little confused:
https://patchwork.kernel.org/patch/5792411/ was already posted. would
you suggest improvements?
Oh, nothing to be confused by, I just missed the earlier patch. I
withdraw mine.
- Paul
Re: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
On Mon, 9 Feb 2015, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [150209 08:04]:
On Mon, 9 Feb 2015, Peter Ujfalusi wrote:
On 02/06/2015 09:26 PM, Peter Ujfalusi wrote:
Yeah, I've never really bothered with data too much, its a debug
feature. So lock_class_key is 8 bytes, and strictly speaking you could
union them over other fields, all we really need is unique addresses,
we
don't actually use the storage.
True. our omap2plus defconfig does not have LOCKDEP enabled so it
should not
add anything to the data when running default kernel.
I'll test the lockdep_set_class() method you suggested on Monday (not
tomorrow), but still as first thing.
If it is working as expected I'll send a patch with you as author.
With omap2plus_defconfig my build produces (vmlinux size):
Base: 99905522
with my series: 99908385 (base + 2863)
with Peter Zijlstra's patch: 99910625 (base + 5103)
The reason for this is that we will only have
struct lock_class_key { };
in case of !CONFIG_LOCKDEP. On ARM however CONFIG_LOCKDEP is enabled by
default, while the CONFIG_DEBUG_LOCKDEP is disabled.
So it does add more data to our default omap2plus config.
Tony: do you have preference on the way we fix this issue?
As I recall there is a plan to remove the hwmod static database and move
it or
generate it from DT? Not sure when and how this will be done, but will it
affect the lockdep_set_class() way?
Well I guess we could see what Tony says, but you do realize that the
difference in sizes that you posted above is about .003% of the total
binary size, right?
If there's one thing we can say about the last few years of ARM kernel
development, it's that those kind of size increases are utterly dwarfed by
other changes in the kernel. So I'd say, post a patch based on PeterZ's
fix and be done with it...
Well the thing to consider here is what Peter U is saying about
having struct omap_hwmod allocated based on the data from .dts
files. If the fix makes the dynamic allocation harder to do later on,
we should probably avoid it. If it's relatively easy to do later on,
then I don't have a problem with it.
The future destination for that code that makes the most sense to me is
for it to become integrated with the OMAP Sonics Arteris bus drivers and
DT data. So I wouldn't worry too much about it; I don't think the
lockdep fix will affect that at all.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thermal: ti-soc-thermal: fix compilation warnings when !CONFIG_PM_SLEEP
When CONFIG_PM_SLEEP=n, the following compilation warnings appear:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
‘ti_bandgap_suspend’ defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
‘ti_bandgap_resume’ defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
A few years ago, suspend/resume-related code was protected by CONFIG_PM.
But that was changed and now it's protected by CONFIG_PM_SLEEP. Fix the
warnings by converting the preprocessor test in the TI bandgap thermal
sensor driver from testing CONFIG_PM to testing CONFIG_PM_SLEEP.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
Non-critical. Targeted for either v3.20-rc1 or v3.21-rc1.
Basic test reports for a series that includes this patch (and a few other
unrelated warning cleanups) is available here:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Compare to:
http://www.pwsan.com/omap/testlogs/test_v3.19-rc7/20150204213018/
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce0e63a..62a5d449c388 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
2.1.4
[PATCH] ARM: omap1_defconfig: drop obsolete Kconfig symbols
scripts/checkkconfigsymbols.py indicates that omap1_defconfig references the following obsolete Kconfig symbols: CONFIG_BT_L2CAP CONFIG_BT_SCO CONFIG_DEBUG_ERRORS CONFIG_EXPERIMENTAL CONFIG_FB_OMAP_BOOTLOADER_INIT CONFIG_LEDS_CPU CONFIG_MACH_OMAP_HTCWIZARD CONFIG_MTD_CHAR CONFIG_MTD_DEBUG CONFIG_MTD_DEBUG_VERBOSE CONFIG_MTD_PARTITIONS CONFIG_NET_ETHERNET CONFIG_RCU_CPU_STALL_DETECTOR CONFIG_SCSI_MULTI_LUN CONFIG_USB_DEVICE_CLASS CONFIG_VIDEO_OUTPUT_CONTROL Drop them from omap1_defconfig. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Paul Bolle pebo...@tiscali.nl Cc: Valentin Rothberg valentinrothb...@gmail.com Cc: Stefan Hengelein stefan.hengel...@fau.de Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org --- Non-critical. Targeted for v3.20-rc1 or v3.21-rc1. I'm unable to boot test it since I don't have any OMAP1 devices currently active in the testbed, but it least compiles and deals with the Kconfig checker warnings: http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/ arch/arm/configs/omap1_defconfig | 16 1 file changed, 16 deletions(-) diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig index a7dce674f1be..0c8a78734536 100644 --- a/arch/arm/configs/omap1_defconfig +++ b/arch/arm/configs/omap1_defconfig @@ -1,4 +1,3 @@ -CONFIG_EXPERIMENTAL=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y @@ -34,7 +33,6 @@ CONFIG_ARCH_OMAP16XX=y CONFIG_MACH_OMAP_INNOVATOR=y CONFIG_MACH_OMAP_H2=y CONFIG_MACH_OMAP_H3=y -CONFIG_MACH_OMAP_HTCWIZARD=y CONFIG_MACH_HERALD=y CONFIG_MACH_OMAP_OSK=y CONFIG_MACH_OMAP_PERSEUS2=y @@ -55,7 +53,6 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT=y CONFIG_AEABI=y CONFIG_LEDS=y -CONFIG_LEDS_CPU=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE=root=1f03 rootfstype=jffs2 @@ -80,8 +77,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_IPV6=y CONFIG_NETFILTER=y CONFIG_BT=y -CONFIG_BT_L2CAP=y -CONFIG_BT_SCO=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y @@ -92,11 +87,7 @@ CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y # CONFIG_PROC_EVENTS is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=3 -CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y @@ -113,11 +104,9 @@ CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_CHR_DEV_SG=y -CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_TUN=y CONFIG_PHYLIB=y -CONFIG_NET_ETHERNET=y CONFIG_SMC91X=y CONFIG_USB_CATC=y CONFIG_USB_KAWETH=y @@ -158,7 +147,6 @@ CONFIG_SPI_OMAP_UWIRE=y CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y CONFIG_OMAP_WATCHDOG=y -CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y @@ -168,7 +156,6 @@ CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_HWA742=y CONFIG_FB_OMAP_MANUAL_UPDATE=y CONFIG_FB_OMAP_LCD_MIPID=y -CONFIG_FB_OMAP_BOOTLOADER_INIT=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_FRAMEBUFFER_CONSOLE=y @@ -194,7 +181,6 @@ CONFIG_SND_OMAP_SOC=y # CONFIG_USB_HID is not set CONFIG_USB=y CONFIG_USB_PHY=y -# CONFIG_USB_DEVICE_CLASS is not set CONFIG_USB_MON=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_STORAGE=y @@ -261,9 +247,7 @@ CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_DEBUG_USER=y -CONFIG_DEBUG_ERRORS=y CONFIG_SECURITY=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_PCBC=y -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
Building an OMAP1510-only Kconfig generates the following warnings:
arch/arm/mach-omap1/pm.c: In function ‘omap1_pm_idle’:
arch/arm/mach-omap1/pm.c:123:2: warning: #warning Enable 32kHz OS timer in
order to allow sleep states in idle [-Wcpp]
#warning Enable 32kHz OS timer in order to allow sleep states in idle
^
arch/arm/mach-omap1/pm.c: At top level:
arch/arm/mach-omap1/pm.c:76:23: warning: ‘enable_dyn_sleep’ defined but not
used [-Wunused-variable]
static unsigned short enable_dyn_sleep = 0;
^
These are not so easy to fix in an obviously correct fashion, since I
don't have these devices up and running in my testbed. So, use
arch/arm/plat-omap/Kconfig and the existing pm.c source as a guide,
and posit that deep power saving states are only supported on OMAP16xx
chips with kernels built with both CONFIG_OMAP_DM_TIMER=y and
CONFIG_OMAP_32K_TIMER=y.
While here, clean up a few printk()s and unnecessary #ifdefs.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jon Hunter jonath...@nvidia.com
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Tuukka Tikkanen tuukka.tikka...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
Hi folks, if anyone out there is still experimenting with OMAP1 PM, or has
a copy of the OMAP1510 TRMs, could you please check this patch? I'm
unable to test it since I don't have any OMAP1 devices currently active
in the testbed. It at least compiles and deals with the build warnings:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Non-critical; targeted for v3.20-rc1 or v3.21-rc1.
arch/arm/mach-omap1/pm.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 34b4c0044961..d46d8a222fbb 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,13 +71,7 @@ static unsigned int
mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifndef CONFIG_OMAP_32K_TIMER
-
-static unsigned short enable_dyn_sleep = 0;
-
-#else
-
-static unsigned short enable_dyn_sleep = 1;
+static unsigned short enable_dyn_sleep;
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
@@ -90,8 +84,9 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
{
unsigned short value;
if (sscanf(buf, %hu, value) != 1 ||
- (value != 0 value != 1)) {
- printk(KERN_ERR idle_sleep_store: Invalid value\n);
+ (value != 0 value != 1) ||
+ (value != 0 !IS_ENABLED(CONFIG_OMAP_32K_TIMER))) {
+ pr_err(idle_sleep_store: Invalid value\n);
return -EINVAL;
}
enable_dyn_sleep = value;
@@ -101,7 +96,6 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
static struct kobj_attribute sleep_while_idle_attr =
__ATTR(sleep_while_idle, 0644, idle_show, idle_store);
-#endif
static void (*omap_sram_suspend)(unsigned long r0, unsigned long r1) = NULL;
@@ -120,12 +114,11 @@ void omap1_pm_idle(void)
local_fiq_disable();
#if defined(CONFIG_OMAP_MPU_TIMER) !defined(CONFIG_OMAP_DM_TIMER)
-#warning Enable 32kHz OS timer in order to allow sleep states in idle
use_idlect1 = use_idlect1 ~(1 9);
-#else
+#endif
+
if (enable_dyn_sleep)
do_sleep = 1;
-#endif
#ifdef CONFIG_OMAP_DM_TIMER
use_idlect1 = omap_dm_timer_modify_idlect_mask(use_idlect1);
@@ -635,15 +628,24 @@ static const struct platform_suspend_ops omap_pm_ops = {
static int __init omap_pm_init(void)
{
-
-#ifdef CONFIG_OMAP_32K_TIMER
- int error;
-#endif
+ int error = 0;
if (!cpu_class_is_omap1())
return -ENODEV;
- printk(Power Management for TI OMAP.\n);
+ pr_info(Power Management for TI OMAP.\n);
+
+ if (!IS_ENABLED(CONFIG_OMAP_32K_TIMER))
+ pr_info(OMAP1 PM: sleep states in idle disabled due to no
32KiHz timer\n);
+
+ if (!IS_ENABLED(CONFIG_OMAP_DM_TIMER))
+ pr_info(OMAP1 PM: sleep states in idle disabled due to no
DMTIMER support\n);
+
+ if (IS_ENABLED(CONFIG_OMAP_32K_TIMER)
+ IS_ENABLED(CONFIG_OMAP_DM_TIMER) cpu_is_omap16xx()) {
+ pr_info(OMAP1 PM: sleep states in idle enabled\n);
+ enable_dyn_sleep = 1;
+ }
/*
* We copy the assembler sleep/wakeup routines to SRAM.
@@ -693,17 +695,15 @@ static int __init omap_pm_init(void)
omap_pm_init_debugfs();
#endif
-#ifdef CONFIG_OMAP_32K_TIMER
error = sysfs_create_file(power_kobj
Re: OMAP baseline test results for v3.19-rc7
On Tue, 3 Feb 2015, Paul Walmsley wrote: vmlinux object size (delta in bytes from test_v3.19-rc6 (26bc420b59a38e4e6685a73345a0def461136dce)): text data bsstotal kernel +364 +800 +444 omap1_defconfig +396 +800 +476 omap1_defconfig_1510innovator_only +364 +480 +412 omap1_defconfig_5912osk_only +99570+5096 +320 +104986 multi_v7_defconfig -522133 -33016-2880 -558029 omap2plus_defconfig -504092 -26904-2816 -533812 omap2plus_defconfig_2430sdp_only -534205 -28088-2816 -565109 omap2plus_defconfig_am33xx_only -521309 -27768-2816 -551893 omap2plus_defconfig_am43xx_only -522133 -33008-2880 -558021 omap2plus_defconfig_cpupm -521309 -30328-2816 -554453 omap2plus_defconfig_dra7xx_only -46578 -912 -180 -47670 omap2plus_defconfig_n800_multi_omap2xxx -46610 -944 -180 -47734 omap2plus_defconfig_n800_only_a -518949 -32936-2816 -554701 omap2plus_defconfig_no_pm -525661 -28024-2816 -556501 omap2plus_defconfig_omap2_4_only -504945 -27888-2880 -535713 omap2plus_defconfig_omap3_4_only -525405 -29936-2816 -558157 omap2plus_defconfig_omap5_only -320 +32 +56 -232 rmk_omap3430_ldp_allnoconfig +73600 +736 rmk_omap3430_ldp_oldconfig -2800 +48 -232 rmk_omap4430_sdp_allnoconfig +728 -240 +704 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.19-rc6 (26bc420b59a38e4e6685a73345a0def461136dce)) avail rsrvd high freed board kconfig 52k -52k . . 2420n800 omap2plus_defconfig_n800_only_a 536k -536k . . 2430sdpomap2plus_defconfig 540k -540k . . 3530es31beagle omap2plus_defconfig 540k -540k . . 3530es3beagle omap2plus_defconfig 536k -536k . . 3730beaglexm omap2plus_defconfig 536k -536k . . 3730es12beaglexmomap2plus_defconfig 540k -540k . . 37xxevmomap2plus_defconfig 540k -540k . . 4430es2panda omap2plus_defconfig 540k -540k . . 4460pandaesomap2plus_defconfig 540k -540k . . 4460varsomom omap2plus_defconfig 540k -540k . . 5430es2sbct54 omap2plus_defconfig 536k -536k . . 5430es2uevmomap2plus_defconfig 548k -548k .-4k am335xbone omap2plus_defconfig_am33xx_only 536k -536k . . am335xbonelt omap2plus_defconfig While in general it's nice to see kernel memory consumption decrease, it's disturbing to see it happen between an -rc6 and -rc7 release. Looked into this further. It turns out that the Kconfigs for this test run were generated from an older kernel version, so the Kconfigs don't match what's in v3.19-rc7. I've added an additional verification check that should catch this if it happens again, and will post a corrected test run shortly. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.19-rc7 (corrected)
Here are some basic OMAP test results for Linux v3.19-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc7/20150204213018/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 2/17): 4460varsomom, 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 3/20): omap1_defconfig, omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v3.19-rc6 (26bc420b59a38e4e6685a73345a0def461136dce)): text data bsstotal kernel +24 +560 +80 omap1_defconfig +56 +320 +88 omap1_defconfig_1510innovator_only +24 +320 +56 omap1_defconfig_5912osk_only -1224 -80-1232 multi_v7_defconfig +908 +640 +972 omap2plus_defconfig +716 +640 +780 omap2plus_defconfig_2430sdp_only +908 -80 +900 omap2plus_defconfig_am33xx_only +972 +880+1060 omap2plus_defconfig_am43xx_only +908 +560 +964 omap2plus_defconfig_cpupm +908 +560 +964 omap2plus_defconfig_dra7xx_only -22800 -228 omap2plus_defconfig_n800_multi_omap2xxx -22800 -228 omap2plus_defconfig_n800_only_a +908 +880 +996 omap2plus_defconfig_no_pm +972 +880+1060 omap2plus_defconfig_omap2_4_only +908 +640 +972 omap2plus_defconfig_omap3_4_only -3188 +640-3124 omap2plus_defconfig_omap5_only -320 +32 +56 -232 rmk_omap3430_ldp_allnoconfig +73600 +736 rmk_omap3430_ldp_oldconfig
OMAP baseline test results for v3.19-rc7
Here are some basic OMAP test results for Linux v3.19-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc7/20150201224202/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 1/17): multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 4/17): 4430es2panda, 4460varsomom, cmt3517, 5430es2uevm PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom vmlinux object size (delta in bytes from test_v3.19-rc6 (26bc420b59a38e4e6685a73345a0def461136dce)): text data bsstotal kernel +364 +800 +444 omap1_defconfig +396 +800 +476 omap1_defconfig_1510innovator_only +364 +480 +412 omap1_defconfig_5912osk_only +99570+5096 +320 +104986 multi_v7_defconfig -522133 -33016-2880 -558029 omap2plus_defconfig -504092 -26904-2816 -533812 omap2plus_defconfig_2430sdp_only -534205 -28088-2816 -565109 omap2plus_defconfig_am33xx_only -521309 -27768-2816 -551893 omap2plus_defconfig_am43xx_only -522133 -33008-2880 -558021 omap2plus_defconfig_cpupm -521309 -30328-2816 -554453 omap2plus_defconfig_dra7xx_only -46578 -912 -180 -47670 omap2plus_defconfig_n800_multi_omap2xxx -46610 -944 -180 -47734 omap2plus_defconfig_n800_only_a -518949 -32936-2816 -554701 omap2plus_defconfig_no_pm -525661 -28024-2816 -556501 omap2plus_defconfig_omap2_4_only -504945 -27888-2880 -535713 omap2plus_defconfig_omap3_4_only -525405 -29936-2816 -558157 omap2plus_defconfig_omap5_only -320 +32 +56 -232 rmk_omap3430_ldp_allnoconfig +73600 +736 rmk_omap3430_ldp_oldconfig -2800 +48 -232 rmk_omap4430_sdp_allnoconfig +728 -240 +704 rmk_omap4430_sdp_oldconfig
OMAP baseline test results for v3.19-rc6
Here are some basic OMAP test results for Linux v3.19-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc6/20150128221837/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom vmlinux object size (delta in bytes from test_v3.19-rc5 (ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc)): text data bsstotal kernel +252 +320 +284 omap1_defconfig +252 +400 +292 omap1_defconfig_1510innovator_only +252 +320 +284 omap1_defconfig_5912osk_only +1445+24400+3885 multi_v7_defconfig +3345+29520+6297 omap2plus_defconfig +10263 +384 +8 +10655 omap2plus_defconfig_2430sdp_only +10791 +7680 +11559 omap2plus_defconfig_am33xx_only +10919+14160 +12335 omap2plus_defconfig_am43xx_only +3281+29440+6225 omap2plus_defconfig_cpupm +6887+13440+8231 omap2plus_defconfig_dra7xx_only +10187 +6080 +10795 omap2plus_defconfig_n800_multi_omap2xxx +10066 +5440 +10610 omap2plus_defconfig_n800_only_a +3277+30080+6285 omap2plus_defconfig_no_pm +7377+16000+8977 omap2plus_defconfig_omap2_4_only +3277+16000+4877 omap2plus_defconfig_omap3_4_only +10919+13360 +12255 omap2plus_defconfig_omap5_only +172 +324 -24 +472 rmk_omap3430_ldp_allnoconfig +508 +3920 +900 rmk_omap3430_ldp_oldconfig +580+1028 -96+1512 rmk_omap4430_sdp_allnoconfig +972+10480+2020
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Hi On Tue, 27 Jan 2015, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
On Tue, 27 Jan 2015, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 11:15:32AM -0600, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 05:12:05PM +, Paul Walmsley wrote: On Tue, 27 Jan 2015, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 01:49:33PM -0600, Felipe Balbi wrote: On Mon, Jan 26, 2015 at 10:56:40AM -0600, Felipe Balbi wrote: hm... modulemode SWCTRL causes wait_target_ready to fail. Any hints ? gets stuck in transition state. PRCM_CM_WKUP_DBGSS_CLKCTRL is always read as 0x 12510f00 which would translate into: - module disabled - all opt clocks are on - module is transitioning - module in standby - clkA as TPIU and STM trace clock - all dividers set to 2 just fyi, checking with HW folks, this might be a new bug, unless debugss needs something special. If that happens on DEBUGSS disable, it's probably the same issue as on AM33xx: http://www.spinics.net/lists/arm-kernel/msg320801.html http://www.spinics.net/lists/arm-kernel/msg321930.html http://www.spinics.net/lists/arm-kernel/msg329151.html Does adding HWMOD_INIT_NO_IDLE fix the issue you're seeing? I'll try it out in a bit... nope, same thing. [ 27.633235] omap_hwmod: debugss: _wait_target_disable failed OK, looking at the code, this makes sense. So here's what I'd suggest asking the hardware team: is the right approach to: 1. keep the DEBUGSS CLKCTRL MODULEMODE bitfield at 0x2 all the time, even when it's not in use or when entering chip low-power states, or 2. program the DEBUGSS CLKCTRL MODULEMODE bitfield to 0x0 when the DEBUGSS is not in use or when entering chip low-power states, but ignore the DEBUGSS CLKCTRL IDLEST register We'll need a new hwmod flag either way; the question is whether it should be something like HWMOD_CANNOT_DISABLE (case 1), or HWMOD_DISABLE_IGNORE_IDLEST (case 2). - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi Prabhakar,
On Mon, 26 Jan 2015, Lad, Prabhakar wrote:
Hi Benoit,
On Mon, Jan 26, 2015 at 3:50 PM, Benoit Parrot bpar...@ti.com wrote:
Lad, Prabhakar prabhakar.cse...@gmail.com wrote on Mon [2015-Jan-26
08:13:01 +]:
Hi Paul,
Thanks for the review.
On Mon, Jan 26, 2015 at 2:15 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Sun, 25 Jan 2015, Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds VPFE HWMOD data for AM43xx.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Hi Paul,
You were right, the hardware team has confirmed that, the VPFE master
port is
connected to L3 and the VPFE slave port is connected to L4. The L3
port cannot
serve as a register target because it is initiator only.
OK makes sense to me.,
I have created links referring to dss l3/l4 hwmod and tested it, lemme
know
if I have missed something.
A few minor comments below
[Snip]
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -788,6 +826,36 @@ static struct omap_hwmod_ocp_if
am43xx_l4_ls__dss_rfbi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am43xx_vpfe0_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
OCPIF_SWSUP_IDLE probably isn't needed here. Could you please try
without
it?
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am43xx_vpfe1_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
Same point as the above.
Dropped and tested works! posting a v3.
When you tested it without the OCPIF_SWSUP_IDLE, did you go trhough a
complete suspend/resume cycle?
This flag was added early on because otherwise the susbsytem would not go
idle without it...
Can you post the console output during a suspend/resume cycle?
Ah I didn’t test the suspend/resume will do and post the console log.
Could you also do a suspend/resume test on v2?
thanks
- Paul
Re: [PATCH 1/4] arm: omap: hwmod: 43xx: add DebugSS hwmod data
Hi
the references below are from SPRUHL7
On Fri, 23 Jan 2015, Felipe Balbi wrote:
Without hwmod data for DebugSS, performance monitors
have no chance of running on AM43xx devices.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 40
++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 41 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c8410160e..6709704dd5b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,7 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include prm44xx.h
#include omap_hwmod_common_data.h
@@ -60,6 +61,44 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
.rst_lines_cnt = ARRAY_SIZE(am33xx_wkup_m3_resets),
};
+/*
+ * 'debugss' class
+ * debug and emulation sub system
+ */
+static struct omap_hwmod_opt_clk am43xx_debugss_opt_clks[] = {
+ { .role = dbg_sysclk, .clk = dbg_sysclk_ck },
+ { .role = dbg_clka, .clk = dbg_clka_ck, },
+ { .role = dbg_clkb, .clk = dbg_clkb_ck, },
+ { .role = dbg_clkc, .clk = dbg_clkc_ck, },
+};
+
+static struct omap_hwmod_class am43xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+/* debugss */
+static struct omap_hwmod am43xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am43xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = trace_clk_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET,
According to Table 6-275 PRCM_CM_WKUP_DBGSS_CLKCTRL Register Field
Descriptions this should have a
.modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = am43xx_debugss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(am43xx_debugss_opt_clks),
+};
+
+/* debugss - l3_main_2 */
+static struct omap_hwmod_ocp_if am43xx_debugss__l3_main = {
+ .master = am43xx_debugss_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= sys_clkin_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
According to Table 31-25 Debug Modules Memory Mapping there are a few
initiator ports on the DEBUGSS that are connected to various slave ports
on various chip-wide interconnects: L3_EMU, L4_PER, L4_WAKEUP, L4_CFG. I
would suggest starting by adding at least one of them as a struct
omap_hwmod_ocp_if record. The one attached to L3_EMU would seem like a
good one to start with.
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9977f8..bb42cd80526d 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -93,6 +93,7 @@
#define AM43XX_CM_PER_TIMER5_CLKCTRL_OFFSET 0x0548
#define AM43XX_CM_PER_TIMER6_CLKCTRL_OFFSET 0x0550
#define AM43XX_CM_PER_TIMER7_CLKCTRL_OFFSET 0x0558
+#define AM43XX_CM_WKUP_DBGSS_CLKCTRL_OFFSET 0x0020
#define AM43XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET0x0228
#define AM43XX_CM_WKUP_CONTROL_CLKCTRL_OFFSET0x0360
#define AM43XX_CM_WKUP_SMARTREFLEX0_CLKCTRL_OFFSET 0x0350
--
2.3.0-rc1
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi
On Sun, 25 Jan 2015, Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds VPFE HWMOD data for AM43xx.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Hi Paul,
You were right, the hardware team has confirmed that, the VPFE master port is
connected to L3 and the VPFE slave port is connected to L4. The L3 port
cannot
serve as a register target because it is initiator only.
OK makes sense to me.,
I have created links referring to dss l3/l4 hwmod and tested it, lemme know
if I have missed something.
A few minor comments below
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 72
++
arch/arm/mach-omap2/prcm43xx.h | 3 +-
2 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c6c841..3787824 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -514,6 +514,44 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
},
};
+static struct omap_hwmod_class_sysconfig am43xx_vpfe_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x104,
+ .sysc_flags = SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_SMART | MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class am43xx_vpfe_hwmod_class = {
+ .name = vpfe,
+ .sysc = am43xx_vpfe_sysc,
+};
+
+static struct omap_hwmod am43xx_vpfe0_hwmod = {
+ .name = vpfe0,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs = AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET,
+ },
+ },
+};
+
+static struct omap_hwmod am43xx_vpfe1_hwmod = {
+ .name = vpfe1,
+ .class = am43xx_vpfe_hwmod_class,
+ .clkdm_name = l3s_clkdm,
+ .prcm = {
+ .omap4 = {
+ .modulemode = MODULEMODE_SWCTRL,
+ .clkctrl_offs = AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -788,6 +826,36 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am43xx_vpfe0_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
OCPIF_SWSUP_IDLE probably isn't needed here. Could you please try without
it?
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am43xx_vpfe1_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
Same point as the above.
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe0 = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_vpfe0_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__vpfe1 = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_vpfe1_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -887,6 +955,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l3__vpfe0,
+ am43xx_l3__vpfe1,
+ am43xx_l4_ls__vpfe0,
+ am43xx_l4_ls__vpfe1,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index ad7b3e9..8aa4c2c 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -143,5 +143,6 @@
#define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
#define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET 0x05C0
#define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
-
+#define AM43XX_CM_PER_VPFE0_CLKCTRL_OFFSET 0x0068
+#define AM43XX_CM_PER_VPFE1_CLKCTRL_OFFSET 0x0070
Re: [PATCH 13/23] ARM: OMAP2+: CM: determine CM base address from device tree
Hi Tero
On Thu, 27 Nov 2014, Tero Kristo wrote:
There is no need to provide the CM base address through a low-level API
from the low-level IO init, as this information is available through DT.
Re-routed the parsing function to be called from the CM drivers also to
simplify the implementation under io.c.
Signed-off-by: Tero Kristo t-kri...@ti.com
This one breaks boot on OMAP2430 (and presumably all other OMAP2xxx).
Adding something like this seems to get it working.
- Paul
---
arch/arm/mach-omap2/cm_common.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c
index c2d7c7b3002c..1770364f0499 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -234,7 +234,12 @@ static struct omap_prcm_init_data omap3_cm_data = {
.offset = -OMAP3430_IVA2_MOD,
};
+static struct omap_prcm_init_data omap2_prcm_data = {
+ .index = CLK_MEMMAP_INDEX_CM1,
+};
+
static struct of_device_id omap_cm_dt_match_table[] = {
+ { .compatible = ti,omap2-prcm, .data = omap2_prcm_data },
{ .compatible = ti,omap3-cm, .data = omap3_cm_data },
{ .compatible = ti,omap4-cm1, .data = cm_data },
{ .compatible = ti,omap4-cm2, .data = cm2_data },
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/23] ARM: OMAP4: omapdss: remove legacy pad muxing support
On Thu, 27 Nov 2014, Tero Kristo wrote: OMAP4 is DT only now, so the legacy mux support is not needed anymore. Padconf is used instead from the driver / DT. This removes the need for having the mux APIs exported from the control module driver. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Dropping since Tomi mentioned legacy mux support is still in use. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/23] ARM: OMAP4: control: remove support for legacy padconf APIs
On Thu, 27 Nov 2014, Tero Kristo wrote: These are no longer needed for anything with the introduction of pinctrl DT support, thus removed. Signed-off-by: Tero Kristo t-kri...@ti.com Dropping since Tomi mentioned that the legacy mux support is still in use. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/23] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
+ Tomi
On Thu, 27 Nov 2014, Tero Kristo wrote:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are separated,
they can logically just access the clock driver not needing to go through
common PRM code. This would be wrong in the case of control module for
example.
Signed-off-by: Tero Kristo t-kri...@ti.com
This patch moves things in the wrong direction (ie, rather than keeping
the PRM register accesses in the PRM code, it moves PRM register accesses
into the clock code). But I see that a subsequent patch in this series
moves them back. So this change is temporary and that seems reasonable to
me.
However, as long as the clock code wants to do low-level register accesses
to PRM/CM/SCM registers, there needs to be some way to keep register
updates originating from the clock code from racing with register updates
coming from other code (e.g. non-clock-related PRM/CM/SCM accesses). So
I've changed this patch to use regmap (as below), and the followup patch
later in the series will be changed too. Seems to work so far but let's
see how things go with the rest of the series.
- Paul
---
arch/arm/mach-omap2/clock.c | 103 ++
arch/arm/mach-omap2/clock.h | 4 +-
arch/arm/mach-omap2/prcm-common.h | 2 +
arch/arm/mach-omap2/prm_common.c | 34 +
4 files changed, 97 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 6ad5b4dbd33e..5fd03e17560f 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -24,6 +24,8 @@
#include linux/io.h
#include linux/bitops.h
#include linux/clk-private.h
+#include linux/of_address.h
+#include linux/regmap.h
#include asm/cpu.h
#include trace/events/power.h
@@ -73,32 +75,111 @@ struct ti_clk_features ti_clk_features;
static bool clkdm_control = true;
static LIST_HEAD(clk_hw_omap_clocks);
-void __iomem *clk_memmaps[CLK_MAX_MEMMAPS];
+static struct regmap *clk_memmaps[CLK_MAX_MEMMAPS];
+
+static struct regmap_config prcm_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .fast_io= 1,
+};
+
+static void clk_memmap_writel(u32 val, void __iomem *reg)
+{
+ struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
+
+ /*
+* XXX Can't really continue if an error occurred here, since
+* this function assumes that the write will always succeed
+*/
+ if (regmap_write(clk_memmaps[r-index], r-offset, val)) {
+ WARN(1, omap clock regmap write to %d %d failed\n,
+r-index, r-offset);
+ BUG();
+ }
+}
+
+static u32 clk_memmap_readl(void __iomem *reg)
+{
+ struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
+ unsigned int val = 0;
+
+ /*
+* XXX Can't really continue if an error occurred here, since
+* this function assumes that the read will always succeed
+*/
+ if (regmap_read(clk_memmaps[r-index], r-offset, val)) {
+ WARN(1, omap clock regmap read from %d %d failed\n,
+r-index, r-offset);
+ BUG();
+ }
+
+ return val;
+}
void omap2_clk_writel(u32 val, struct clk_hw_omap *clk, void __iomem *reg)
{
- if (clk-flags MEMMAP_ADDRESSING) {
- struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
- writel_relaxed(val, clk_memmaps[r-index] + r-offset);
- } else {
+ if (clk-flags MEMMAP_ADDRESSING)
+ clk_memmap_writel(val, reg);
+ else
writel_relaxed(val, reg);
- }
}
u32 omap2_clk_readl(struct clk_hw_omap *clk, void __iomem *reg)
{
u32 val;
- if (clk-flags MEMMAP_ADDRESSING) {
- struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
- val = readl_relaxed(clk_memmaps[r-index] + r-offset);
- } else {
+ if (clk-flags MEMMAP_ADDRESSING)
+ val = clk_memmap_readl(reg);
+ else
val = readl_relaxed(reg);
- }
return val;
}
+static struct ti_clk_ll_ops omap_clk_ll_ops = {
+ .clk_readl = clk_memmap_readl,
+ .clk_writel = clk_memmap_writel,
+};
+
+/**
+ * omap2_clk_provider_init - initialize a clock provider
+ * @match_table: DT device table to match for devices to init
+ *
+ * Initializes a clock provider module (CM/PRM etc.), allocating the
+ * memory mapping, allocating the mapping index and initializing the
+ * low level driver infrastructure. Returns 0 in success, -ENOMEM in
+ * failure.
+ */
+int __init omap2_clk_provider_init(const struct of_device_id *match_table)
+{
+ struct device_node *np;
+ void __iomem *mem;
+ static int memmap_index;
+ struct regmap *regmap;
+
+ ti_clk_ll_ops = omap_clk_ll_ops;
+
+ for_each_matching_node(np, match_table) {
Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support
Hi Tony
thought about this some more overnight...
On Fri, 23 Jan 2015, Paul Walmsley wrote:
On Tue, 20 Jan 2015, Tony Lindgren wrote:
+/* L3 Interconnect entries */
+static struct omap_hwmod dm816x_l3_s_hwmod = {
+ .name = l3_s,
Would suggest naming this l3_slow
+ .clkdm_name = alwon_l3s_clkdm,
+ .class = l3_hwmod_class,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+static struct omap_hwmod __used dm816x_l3_med_hwmod = {
Hmm, why __used for this -- maybe just add it to the hwmod list at the
bottom?
+ .name = l3_med,
+ .clkdm_name = alwon_l3_med_clkdm,
+ .class = l3_hwmod_class,
+ .flags = HWMOD_NO_IDLEST,
+};
+
+static struct omap_hwmod __used dm816x_l3_fast_hwmod = {
Same __used comment as above.
Looking at the TRM CLKSTCTRL registers for the various L3 buses, it
occurred to me that if we wanted to portray this accurately, we'd
probably need separate hwmods for the ALWON and DEFAULT branches of the L3
as well. So there would be six in total:
{alwon,default}_l3_{slow,med,fast}.
It looks like it's possible to roughly figure out which targets are
associated with which variant of the L3 by looking at the CLKACTIVITY
bits. So for example, it looks like most of the L3 Slow targets are on
ALWON_L3_SLOW according to Table 18-136 CM_ALWON_L3_SLOW_CLKSTCTRL
Register Field descriptions, with the exception of USB, which appears to
be on DEFAULT_L3_SLOW according to Table 18-80
CM_DEFAULT_L3_SLOW_CLKSTCTRL Register Field Descriptions.
Anyway, I'm sorry to put you through this, reverse-engineering this stuff
isn't very pleasant :-( After reflecting on the matter, I would be OK to
ack the merge of the original L3-related hwmod data that you proposed,
with two changes:
- dropping the __used and adding the two hwmods to the list at the bottom,
assuming that the system still boots in that configuration (i.e., if it
doesn't cause problems with the clockdomain programming, since it might
appear that there are no devices/clocks active in those clockdomains)
- adding a comment noting that there probably should be six L3 hwmods as
described above, but that this is left for future work
It would still be cool if you could doublecheck the SYSC/SYSS data for the
other IP blocks that are listed below.
+ .name = l3_fast,
+ .clkdm_name = alwon_l3_fast_clkdm,
+ .class = l3_hwmod_class,
+ .flags = HWMOD_NO_IDLEST,
+};
See below, I screwed up the review comment ordering here...
+
+/*
+ * L4 standard peripherals, see TRM table 1-12 for devices using this.
+ * Devices using this have 125MHz SYSCLK5 clock.
+ */
+static struct omap_hwmod dm816x_l4_ls_hwmod = {
+ .name = l4_ls,
+ .clkdm_name = alwon_l3s_clkdm,
+ .class = l4_hwmod_class,
+ .flags = HWMOD_NO_IDLEST,
Section 18.7.17.46 CM_ALWON_L3_CLKCTRL Register lists an IDLEST bitfield
for this.
Well I meant for this comment to be attached to the l3_fast hwmod. But
thinking about it further, I think this IDLEST is actually associated with
the L3 configuration *register target*, rather than the L3 itself. This
appears to be located at 0x4400, according to the memory map in
Section 1.5.1. Register targets are usually what the IDLEST bits are
intended to protect. So I think it's OK to keep HWMOD_NO_IDLEST for the
l3_fast hwmod, and then later to add a separate hwmod for the L3 config
space.
What I meant to write was:
Section 18.7.17.48 CM_ALWON_L4LS_CLKCTRL Register lists an IDLEST
bitfield for this.
+};
+
+/*
+ * L4 high-speed peripherals. For devices using this, please see the TRM
+ * Table 1-13. L4 High-Speed Peripheral Memory Map. On dm816x, only
+ * EMAC, MDIO and SATA use this.
+ */
+static struct omap_hwmod dm816x_l4_hs_hwmod = {
+ .name = l4_hs,
+ .clkdm_name = alwon_l3_med_clkdm,
+ .class = l4_hwmod_class,
+ .flags = HWMOD_NO_IDLEST,
Section 18.7.17.47 CM_ALWON_L4HS_CLKCTRL Register lists an IDLEST
bitfield for this.
[ ... ]
The 816x TRM is pretty crappy when it comes to integration documentation,
so it's not so easy to figure out what IP blocks are connected to which
initiators. (Maybe it doesn't even matter that much in the long run; I
doubt anyone is going to spend much time on PM or DMA path hacking for
these DM816x chips.) Anyway, I think it's pretty safe to assume that any
IP block with a 128-bit or 64-bit initiator port onto the interconnect
probably isn't connected to the L3 Slow interconnect. So looking at
Figure 1-75 L3 Interconnect Block Diagram and Section 1.11.2.2 L3 Port
Mapping this includes the MPU L3 port, HDVICP2-{0,1,2} initiator ports,
IOMMU, DSP, TPTC, TPCC, VPSS M0/M1 ports, SGX, Media Controller, expansion
slot 0 initiator, EMIF0/1, and PCIe.Similarly I'd assume that anything
Re: [PATCH 1/2] ARM: OMAP2+: Add clock domain support for dm816x
Hi Tony
On Tue, 20 Jan 2015, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [150120 18:08]:
On Tue, 13 Jan 2015, Tony Lindgren wrote:
+/* Common TI81XX */
I can't comment on how many of these are truly common; since I haven't
cross-checked this file against the 814x TRM. But if you haven't had the
chance to cross-check it against the 814x TRM either, I'd suggest starting
by making this file explicitly 816x-specific.
Seem to be common in the old TI PSP tree too at:
http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary
Except it seems that dm814x has CLKDM_CAN_SWSUP while dm816x
has CLKDM_CAN_HWSUP_SWSUP. I've booted that tree only on dm816x
but let's assume it also works for dm814x as that's the TI tree
for it.
Just looked at SPRUGZ8E, the 814x TRM. According to that, it's the 814x
that supports HW_AUTO on more of the clockdomains, compared to the 816x
TRM which states that on that chip, HW_AUTO is only supported on
ALWON_L3_FAST on 816x.
CLKDM_CAN_SWSUP should be safe to use on clockdomains that don't support
HW_AUTO. But using CLKDM_CAN_HWSUP_SWSUP on clockdomains that don't
support HW_AUTO will wind up programming register values marked as
reserved in the TRM.
Here's what I'd suggest. This file is marked as common to all 81xx chips.
So the safe thing to do is to mark all of the clockdomains as
CLKDM_CAN_SWSUP except for ALWON_L3_FAST. (ALWON_L3_FAST is documented as
supporting HW_AUTO on both chips.)
Otherwise, if there's some reason why you'd want to keep
CLKDM_CAN_HWSUP_SWSUP (I can't really think of any, BTW), please add a
comment to the data stating that you're going with the CLKDM_CAN_*
settings from the 816x tree, even though they don't match the TRM; and
that those should be investigated if there's any problem with full chip
idle.
Looks like TI's tree has these ifdef else and 816x seems to
have both CAN_HWSUP_SWSUP so probably the TRM is wrong.
My guess the TRM for 816x has tons of copy-paste errors from the
dm814x TRM. So I've kept all them the same way as the TI tree has
them.
I'd be pretty skeptical of the TI tree data. If there were cut-and-paste
errors for this data from the 814x TRM, then the 816x TRM would show more
clockdomains supporting HW_AUTO. But given the difference in these
documented clockdomain bitfields, I'd say it's unlikely that there are
cut-and-paste issues there.
+static struct clockdomain default_ducati_816x_clkdm = {
I can't find any mention of the Ducati in the TRM. Does this SoC have a
Ducati?
So it seems for dm816x. Also clock816x_data.c references ducati_ick.
...
According to the TRM here, looks like this should just be
default_816x_clkdm ? The corresponding register is named
CM_DEFAULT_CLKSTCTRL. It references two clockdomains, GCLKINTR and
GCLKIN200TR, but I can't find any other mention of those in the TRM, so,
no idea what they're associated with.
No mention of CM_DEFAULT_CLKSTCTRL in the TI tree. It seems the
TRM is wrong here too.
Am thinking they might have rebranded the Ducati as something else.
Maybe they got sued ;-) The dm814x TRM lists DUCATI in the names for
these registers, so it's fine with me to keep using them here.
...
I tried applying a version of this patch, but looks like it has a
dependency on some mach-omap2/io.c changes that I don't have a stable
commit for. How about this: if you can change the CLKDM_CAN_HWSUP_SWSUP
to CLKDM_CAN_SWSUP in most cases, then feel free to add my Reviewed-by:
and to merge it. Otherwise if you'd prefer me to take it upstream, let me
know what stable commit I should base the pull request on.
I appreciate the discussion,
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP2+: Add dm816x hwmod support
Hi Tony
just a few brief comments
On Tue, 20 Jan 2015, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150117 08:38]:
And the sysc and syss offsets for mcspi1 need 0x100 added to them for
it to work, like on am33xx. Updated patch below.
Here's this one updated with the alwon_l3s_clkdm naming changes
Paul commented in the related clockdomain patch.
Regards,
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Tue, 20 Jan 2015 18:24:47 -0800
Subject: [PATCH] ARM: OMAP2+: Add dm816x hwmod support
Add minimal hwmod support that works at least on dm8168. This
is based on the code in the earlier TI CDP tree, and an earlier
patch by Aida Mynzhasova aida.mynzhas...@skitlab.ru.
I've set up things to work pretty much the same way as for
am33xx. We are basically using cm33xx.c with a different set
of clocks and clockdomains.
This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
Cc: Aida Mynzhasova aida.mynzhas...@skitlab.ru
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_ARCH_OMAP4) +=
$(omap-prcm-4-5-common)
obj-$(CONFIG_SOC_OMAP5) += $(omap-prcm-4-5-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common)
am33xx-43xx-prcm-common += prm33xx.o cm33xx.o
+obj-$(CONFIG_SOC_TI81XX) += $(am33xx-43xx-prcm-common)
obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common)
obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \
$(am33xx-43xx-prcm-common)
@@ -225,6 +226,7 @@ obj-$(CONFIG_SOC_AM33XX) +=
omap_hwmod_33xx_43xx_ipblock_data.o
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_43xx_data.o
obj-$(CONFIG_SOC_AM43XX) +=
omap_hwmod_33xx_43xx_interconnect_data.o
obj-$(CONFIG_SOC_AM43XX) += omap_hwmod_33xx_43xx_ipblock_data.o
+obj-$(CONFIG_SOC_TI81XX) += omap_hwmod_81xx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
obj-$(CONFIG_SOC_OMAP5) += omap_hwmod_54xx_data.o
obj-$(CONFIG_SOC_DRA7XX) += omap_hwmod_7xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index ed3e6e8f..e60780f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -545,10 +545,12 @@ void __init ti814x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+ am33xx_prm_init();
+ am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
- omap3xxx_hwmod_init();
+ ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
@@ -564,10 +566,12 @@ void __init ti816x_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(TI81XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
+ am33xx_prm_init();
+ am33xx_cm_init();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
ti81xx_clockdomains_init();
- omap3xxx_hwmod_init();
+ ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
omap_clk_soc_init = ti81xx_dt_clk_init;
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 1c0cb48..be50454 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3916,7 +3916,7 @@ void __init omap_hwmod_init(void)
soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
- } else if (soc_is_am33xx()) {
+ } else if (cpu_is_ti816x() || soc_is_am33xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -748,6 +748,7 @@ extern int omap3xxx_hwmod_init(void);
extern int omap44xx_hwmod_init(void);
extern int omap54xx_hwmod_init(void);
extern int am33xx_hwmod_init(void);
+extern int ti81xx_hwmod_init(void);
extern int dra7xx_hwmod_init(void);
int am43xx_hwmod_init(void);
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -0,0 +1,1025 @@
+/*
+ * DM81xx hwmod data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc
[GIT PULL] ARM: OMAP2+: hwmod: first set of patches for v3.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.20/omap-hwmod-a for you to fetch changes up to 1c7e36bfc3e2fb2df5e2d1989a4b6fb9055a0f9b: ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 (2015-01-20 18:12:17 -0700) - ARM: OMAP2+: hwmod: first set of patches for v3.20 First set of OMAP2+ hwmod patches for Linux v3.20. These are mostly fixes for warnings, although there's one DRA7xx patch that fixes CONFIG_DEBUG_LL for AM572x/DRA7xx SoCs that use UART3 for console, such as the BeagleBoard-X15. These patches entered Linux-next starting with the next-20150121 tag. Basic build, boot, and PM test results can be found here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v3.20/20150121142621/ - Keerthy (1): ARM: OMAP: DRA7: hwmod: Make gpmc software supervised as the smart idle is broken Lokesh Vutla (2): ARM: OMAP2+: hwmod: print error if wait_target_ready() failed ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 Paul Walmsley (1): MAINTAINERS: add maintainer for OMAP hwmod data Tomi Valkeinen (1): ARM: AM43xx: hwmod: set DSS submodule parent hwmods MAINTAINERS| 6 ++ arch/arm/mach-omap2/omap_hwmod.c | 4 ++-- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 5 +++-- 4 files changed, 13 insertions(+), 4 deletions(-) vmlinux object size (delta in bytes from test_v3.19-rc1 (97bf6af1f928216fd6c5a66e8a57bfa95a659672)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only 0000 multi_v7_defconfig 0000 omap2plus_defconfig 0000 omap2plus_defconfig_2430sdp_only +6400 +64 omap2plus_defconfig_am33xx_only 0000 omap2plus_defconfig_am43xx_only 0000 omap2plus_defconfig_cpupm 0000 omap2plus_defconfig_dra7xx_only +3200 +32 omap2plus_defconfig_n800_multi_omap2xxx 0000 omap2plus_defconfig_n800_only_a 0000 omap2plus_defconfig_no_pm 0000 omap2plus_defconfig_omap2_4_only 0000 omap2plus_defconfig_omap3_4_only 0000 omap2plus_defconfig_omap5_only +560 -560 rmk_omap3430_ldp_allnoconfig 0000 rmk_omap3430_ldp_oldconfig +640 -640 rmk_omap4430_sdp_allnoconfig 0000 rmk_omap4430_sdp_oldconfig -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUwDhJAAoJEMePsQ0LvSpLFWsP/38ZfGOlOOex0JDaZSm/tTK2 WP+0RICxClIKFbvi9YHMW5yrrpEEcp7BZmcWsBf6SmJJs8HTzLjulRepz25gwPCw JC0qReQHpHOXIqcIKaJKEP1z0FlXArUF0xInLVRvVObcHKVJ+yuG2vk7Fs6tdZVw K7JS9x/6ZU5gZ7DMpTVuY5cuNcXaiuTb9tmKWrcXCNTneN30rpRq4g6R8kp5hSgI PR4dCkUpEnkgPfuuLUjSNDtIwGHwulgd85O+6gr6uxOvJR3bEHfYP0jvc9XMuBnY /Qy5KvfNjjeItfcBVgZSLusnmFXKFMApPnYJfyaikH9agoy5QFpFdMgS5syLJ5lQ ZCLTqg71UC3sycxZGGgPqddzI+rfHH/0QboonW0+LIhB0VTgA64wH2CIoz0nfmSs rixWz0+5cS2DaxvXRD98+1T3F1MB6wVmJr8IZaPkHT1G9FnsKNsqGd6Qk76ItdMf 8MdFxR0qEjZGK0djOyRiAvXkk2g4o3JE/MBT557eH1oHasaHiyABHqgXxEDFrtXy /gLYUNYSHvyirFERHF0Ub4xamNNPe6WIqu68/o0yq7HxECiOmji83SpK6NfhPgPW mAZxOhHtF67f68sa+nyZV5W9CeQTb23wcmEo9esqARh0IasM7x+mzbxVcemCN9AY RoP0xFh/ncaBH8vv9E// =wq+i -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] arm: omap: hwmod: add debugfs interface
On Tue, 20 Jan 2015, Paul Walmsley wrote: On Fri, 5 Dec 2014, Felipe Balbi wrote: By exposing the details of hwmod structures to debugfs we can much more easily verify that changes to hwmod data is correct and won't cause regressions. The idea is that this can be used to check the state of one hwmod, verify hwmod sysc fields, etc. For example, this will be used to move some of the sysc fields to DT and later verify that they are correct pre- and post-patch. Signed-off-by: Felipe Balbi ba...@ti.com This one had a bunch of unnecessary includes and checkpatch issues (below). I cleaned those up here and have queued the result (also below) for v3.20. ... and, the patch doesn't even boot. Dropped. If you really want something like this to be merged, resend a version that boots, and has checkpatch warnings fixed and unnecessary includes dropped. Otherwise you're just wasting my time. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3
On Thu, 8 Jan 2015, Lokesh Vutla wrote: With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS. On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on BeagleBoard-X15, where we use UART3 for console, boot fails with DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod. For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig. Fixes: 90020c7b2c5e (ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data) Cc: sta...@vger.kernel.org # v3.12+ Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Thanks, queued for v3.20. Note that I don't have a DRA7xx board, so, cannot test. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Add clock domain support for dm816x
Hi
On Tue, 13 Jan 2015, Tony Lindgren wrote:
From: Aida Mynzhasova aida.mynzhas...@skitlab.ru
This patch adds required definitions and structures for clockdomain
initialization, so omap3xxx_clockdomains_init() was substituted by
new ti81xx_clockdomains_init() while early initialization of
TI81XX platform.
This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches
published at:
http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Aida Mynzhasova aida.mynzhas...@skitlab.ru
[t...@atomide.com: updated to apply, renamed to clockdomains81xx.c
fixed to use am33xx_clkdm_operations]
Signed-off-by: Tony Lindgren t...@atomide.com
A few comments below based on SPRUGX8B:
---
arch/arm/mach-omap2/Makefile| 2 +
arch/arm/mach-omap2/clockdomain.h | 1 +
arch/arm/mach-omap2/clockdomains81xx_data.c | 191
arch/arm/mach-omap2/cm81xx.h| 61 +
arch/arm/mach-omap2/io.c| 4 +-
5 files changed, 257 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomains81xx_data.c
create mode 100644 arch/arm/mach-omap2/cm81xx.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3a6463f..352873c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -171,6 +171,8 @@ obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common)
obj-$(CONFIG_ARCH_OMAP4) += clockdomains44xx_data.o
obj-$(CONFIG_SOC_AM33XX) += $(clockdomain-common)
obj-$(CONFIG_SOC_AM33XX) += clockdomains33xx_data.o
+obj-$(CONFIG_SOC_TI81XX) += $(clockdomain-common)
+obj-$(CONFIG_SOC_TI81XX) += clockdomains81xx_data.o
obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common)
obj-$(CONFIG_SOC_AM43XX) += clockdomains43xx_data.o
obj-$(CONFIG_SOC_OMAP5) += $(clockdomain-common)
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 82c37b1..77bab5f 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -216,6 +216,7 @@ extern void __init omap242x_clockdomains_init(void);
extern void __init omap243x_clockdomains_init(void);
extern void __init omap3xxx_clockdomains_init(void);
extern void __init am33xx_clockdomains_init(void);
+extern void __init ti81xx_clockdomains_init(void);
extern void __init omap44xx_clockdomains_init(void);
extern void __init omap54xx_clockdomains_init(void);
extern void __init dra7xx_clockdomains_init(void);
diff --git a/arch/arm/mach-omap2/clockdomains81xx_data.c
b/arch/arm/mach-omap2/clockdomains81xx_data.c
new file mode 100644
index 000..05c4635
--- /dev/null
+++ b/arch/arm/mach-omap2/clockdomains81xx_data.c
@@ -0,0 +1,191 @@
+/*
+ * TI81XX Clock Domain data.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
+ * Copyright (C) 2013 SKTB SKiT, http://www.skitlab.ru/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS_81XX_H
+#define __ARCH_ARM_MACH_OMAP2_CLOCKDOMAINS_81XX_H
+
+#include linux/kernel.h
+#include linux/io.h
+
+#include clockdomain.h
+
+#include cm81xx.h
+
+/*
+ * - Add other domains as required
+ * - Fill up associated powerdomans (especially ALWON powerdomains are NULL
at
+ * the moment
+ * - Consider dependencies across domains (probably not applicable till now)
Minor comment: I guess these are to-do items; would suggest explicitly
putting a To-do header on this list.
+ */
+
+/* Common TI81XX */
I can't comment on how many of these are truly common; since I haven't
cross-checked this file against the 814x TRM. But if you haven't had the
chance to cross-check it against the 814x TRM either, I'd suggest starting
by making this file explicitly 816x-specific.
+static struct clockdomain alwon_l3_slow_81xx_clkdm = {
+ .name = l3s_clkdm,
This should mention alwon in the name like the other L3 always-on
clockdomains, since there's another L3 Slow clockdomain on this chip
that's in the DEFAULT power domain, according to Section 18.7.6.4
CM_DEFAULT_L3_SLOW_CLKSTCTRL Register
+ .pwrdm = { .name = alwon_pwrdm },
+ .cm_inst= TI81XX_CM_ALWON_MOD,
+ .clkdm_offs = TI81XX_CM_ALWON_L3_SLOW_CLKDM,
+ .flags
Re: [RFC/PATCH] arm: omap: hwmod: add debugfs interface
we can much more easily verify
that changes to hwmod data is correct and won't
cause regressions.
The idea is that this can be used to check the
state of one hwmod, verify hwmod sysc fields, etc.
For example, this will be used to move some of
the sysc fields to DT and later verify that they
are correct pre- and post-patch.
Signed-off-by: Felipe Balbi ba...@ti.com
[p...@pwsan.com: removed unnecessary includes, fixed most checkpatch issues]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/omap_hwmod.c | 1 +
arch/arm/mach-omap2/omap_hwmod.h | 6 +
arch/arm/mach-omap2/omap_hwmod_debugfs.c | 258 +++
4 files changed, 266 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_debugfs.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d27dfdef66b..68c9ae5d6524 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -11,7 +11,7 @@ obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o
timer.o pm.o \
omap_device.o sram.o drm.o
hwmod-common = omap_hwmod.o omap_hwmod_reset.o \
- omap_hwmod_common_data.o
+ omap_hwmod_common_data.o
omap_hwmod_debugfs.o
clock-common = clock.o clock_common_data.o \
clkt_dpll.o clkt_clksel.o
secure-common = omap-smc.o omap-secure.o
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..a01caa4f8378 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3314,6 +3314,7 @@ static int __init omap_hwmod_setup_all(void)
omap_hwmod_for_each(_init, NULL);
omap_hwmod_for_each(_setup, NULL);
+ omap_hwmod_debug_init();
return 0;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 35ca6efbec31..84b732bb8693 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -768,4 +768,10 @@ int am43xx_hwmod_init(void);
extern int __init omap_hwmod_register_links(struct omap_hwmod_ocp_if **ois);
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+int __init omap_hwmod_debug_init(void);
+#else
+static inline int __int omap_hwmod_debug_init(void) { return 0; }
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_debugfs.c
b/arch/arm/mach-omap2/omap_hwmod_debugfs.c
new file mode 100644
index ..3ab781564f3b
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_debugfs.c
@@ -0,0 +1,258 @@
+/*
+ * omap_hwmod debugfs view
+ *
+ * Copyright (C) 2014 Texas Instruments, Incorporated - http://www.ti.com
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#undef DEBUG
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/err.h
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+#include omap_hwmod.h
+
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+static int __init omap_hwmod_create_files(struct omap_hwmod *oh,
+ struct dentry *dir)
+{
+ struct dentry *file;
+
+ file = debugfs_create_u16(flags, S_IRUGO, dir, oh-flags);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(mpu_rt_idx, S_IRUGO, dir, oh-mpu_rt_idx);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(response_lat, S_IRUGO, dir,
+oh-response_lat);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(rst_lines_cnt, S_IRUGO, dir,
+oh-rst_lines_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(opt_clks_cnt, S_IRUGO, dir,
+oh-opt_clks_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(masters_cnt, S_IRUGO, dir, oh-masters_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(slaves_cnt, S_IRUGO, dir, oh-slaves_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(hwmods_cnt, S_IRUGO, dir, oh-hwmods_cnt);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(_int_flags, S_IRUGO, dir, oh-_int_flags);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(_state, S_IRUGO, dir, oh-_state);
+ if (!file)
+ return -ENOMEM;
+
+ file = debugfs_create_u8(_postsetup_state, S_IRUGO, dir,
+oh-_postsetup_state);
+ if (!file)
+ return -ENOMEM
Re: [GIT PULL] ARM: OMAP: hwmod fixes for v3.19-rc
Hi Tony On Mon, 19 Jan 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150104 15:38]: The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.19-rc/omap-fixes-a for you to fetch changes up to 99d076b747455449b2eec9e37f3fb0bfdf51af32: MAINTAINERS: add maintainer for OMAP hwmod data (2015-01-02 16:24:27 -0700) For v3.19-rc, fix some hwmod structure details for the OMAP DSS modules for DRA7xx and AM43xx. Also update the MAINTAINERS file to encourage folks to cc me on hwmod data patches. Basic build, boot, and PM testlogs are available here: http://www.pwsan.com/omap/testlogs/omap-fixes-a-for-v3.19-rc/20150103144242/ Paul, got any updates on this? Anyways, I'll just untag this email as you asked me to wait on pulling this. At this point I think I will just requeue the remaining two valid patches for v3.20. Thanks for the ping - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: AM43xx: hwmod: add VPFE hwmod entries
Hi
On Thu, 18 Dec 2014, Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds VPFE HWMOD data for AM43xx.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
...
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 56
++
arch/arm/mach-omap2/prcm43xx.h | 3 +-
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index fea01aa..bd9067e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
...
@@ -750,6 +788,22 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe0 = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am43xx_vpfe0_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l3__vpfe1 = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am43xx_vpfe1_hwmod,
+ .clk= l3_gclk,
+ .flags = OCPIF_SWSUP_IDLE,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -848,6 +902,8 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__dss,
am43xx_l4_ls__dss_dispc,
am43xx_l4_ls__dss_rfbi,
+ am43xx_l3__vpfe0,
+ am43xx_l3__vpfe1,
NULL,
};
According to SPRUHL7 Figure 14-1 VPFE Integration and Table 14-2 VPFE
Connectivity Attributes, a VPFE has two interconnect ports per instance:
one L4-Per port as a register target, and one L3 port as a DMA initiator.
It's unclear to me whether the L3 port can also serve as a register
target, but Section 2.1 ARM Cortex-A9 Memory Map, Table 4-1 L3
Master-Slave Connectivity, and Figure 4-2 L4 Topology suggest that it
cannot.
So if that's correct, there should be two more struct omap_hwmod_ocp_if
records added in this patch for the register target ports that are
connected to the L4. DSS is a good example: see am43xx_dss__l3_main and
am43xx_l4_ls__dss in this same file.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: print error if wait_target_ready() failed
On Fri, 19 Dec 2014, Lokesh Vutla wrote: Fixed pr_debug to pr_err when hwmod returns an error when enabling a module. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Thanks, queued for v3.20 with Roger's ack. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: DRA7: hwmod: Make gpmc software supervised as the smart idle is broken
On Tue, 20 Jan 2015, Keerthy wrote:
On Tuesday 13 January 2015 02:21 PM, Keerthy wrote:
This patch fixes: 'omap_hwmod: gpmc: _wait_target_disable failed'
error during suspend.
This is because smart idle is broken.
Tested in dra7-evm D1 board.
Ping on this.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 9cdd8b8..29e55fe 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -826,7 +826,8 @@ static struct omap_hwmod dra7xx_gpmc_hwmod = {
.name = gpmc,
.class = dra7xx_gpmc_hwmod_class,
.clkdm_name = l3main1_clkdm,
- .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
+ HWMOD_SWSUP_SIDLE),
.main_clk = l3_iclk_div,
.prcm = {
.omap4 = {
Thanks, queued for v3.20.
Note that I cannot test this since I don't have a DRA7xx board.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.19-rc4
Here are some basic OMAP test results for Linux v3.19-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc4/20150118192109/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.19-rc3 (b1940cd21c0f4abdce101253e860feff547291b0)): text data bsstotal kernel +21600 +216 omap1_defconfig +21600 +216 omap1_defconfig_1510innovator_only +21600 +216 omap1_defconfig_5912osk_only +888 +1440+1032 multi_v7_defconfig -6400 -64 omap2plus_defconfig -20000 -200 omap2plus_defconfig_2430sdp_only 0000 omap2plus_defconfig_am33xx_only 0000 omap2plus_defconfig_am43xx_only -6400 -64 omap2plus_defconfig_cpupm 0000 omap2plus_defconfig_dra7xx_only -1200 -12 omap2plus_defconfig_n800_multi_omap2xxx +180 -80 +172 omap2plus_defconfig_n800_only_a 0000 omap2plus_defconfig_no_pm -6400 -64 omap2plus_defconfig_omap2_4_only 0000 omap2plus_defconfig_omap3_4_only -6400 -64 omap2plus_defconfig_omap5_only +2200 -28 +192 rmk_omap3430_ldp_allnoconfig +16000 +160 rmk_omap3430_ldp_oldconfig +2360 -44
OMAP baseline test results for v3.19-rc5
Here are some basic OMAP test results for Linux v3.19-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc5/20150118212155/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.19-rc4 (eaa27f34e91a14cdceed26ed6c6793ec1d186115)): text data bsstotal kernel +127200+1272 omap1_defconfig +1272 -80+1264 omap1_defconfig_1510innovator_only +130400+1304 omap1_defconfig_5912osk_only +1748 +3840+2132 multi_v7_defconfig +5680 +160+5696 omap2plus_defconfig +1324 +240+1348 omap2plus_defconfig_2430sdp_only +1224 +160+1240 omap2plus_defconfig_am33xx_only +1288 -240+1264 omap2plus_defconfig_am43xx_only +5744 +240+5768 omap2plus_defconfig_cpupm +5564 +320+5596 omap2plus_defconfig_dra7xx_only +62000 +620 omap2plus_defconfig_n800_multi_omap2xxx +580 +80 +588 omap2plus_defconfig_n800_only_a +1648 -80+1640 omap2plus_defconfig_no_pm +1380 -80+1372 omap2plus_defconfig_omap2_4_only +1420 +160+1436 omap2plus_defconfig_omap3_4_only +5560 +80+5568 omap2plus_defconfig_omap5_only +844 -8 -128 +708 rmk_omap3430_ldp_allnoconfig +5064 +240+5088 rmk_omap3430_ldp_oldconfig +6920 -112
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Suman, thanks for pitching in on this! On Tue, 6 Jan 2015, Suman Anna wrote: You have removed the return from the above block on failure. If any DT entry doesn't have the reg property, this will hang the kernel boot. Just remove the reg entry from any of the existing DT, and you will run into the issue, this is what 6423d6df1440 (ARM: OMAP2+: hwmod: check for module address space during init) fixed. Seems like that's the problem that we need to track down, then. If a hwmod has no MPU-accessible registers, it should still be possible to init the clocks for the device, etc. ... Also, are you sure you want to turn the WARN into a pr_debug, it won't even show during the kernel boot log if the reg base is missing. No, I'm not sure :-) I guess it depends how many hwmods we'll have with no MPU-accessible registers. We don't seem to have address ranges for the interconnects defined; we could fix that fairly easily. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Hi Suman On Tue, 6 Jan 2015, Suman Anna wrote: Looking at your rc3 log @ http://www.pwsan.com/omap/testlogs/test_v3.19-rc3/20150105224749/boot/4460varsomom/, I do see a missing reg entry for mailbox, and that's the reason for your hang because of the missing bail out in your new patch. [0.261932] [ cut here ] [0.261962] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2458 _init+0x3a0/0x3f0() [0.261962] omap_hwmod: mailbox: doesn't have mpu register target base ... ... [0.262329] ---[ end trace a1be72591db4662e ]--- Now that said, this is weird, since the reg property for mailbox is defined in the base omap4.dtsi and should be inherited by the 4460 VAR-SOM-OM, unless you are booting with an old dtb. Yeah, it doesn't make sense. I'm pretty sure I'm using the right DTB here, since that board is booting with a concatenated uImage + DTB. Well, at least there's a good test platform here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
On Wed, 7 Jan 2015, Roger Quadros wrote:
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+ WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+oh-name);
Not part of $subject.
Hmm, how do you mean? If we skip the ioremap(), wouldn't you like to know
before some custom reset code gets called that pretty much always depends
on the ioremap() succeeding? :-)
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node
*np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct
omap_hwmod *oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+ /*
+* If there's no need for the hwmod code to read or write to
+* the IP block registers, bail out early before the ioremap()
+*/
+ if (!oh-class-sysc)
+ return 0;
+
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r 0) {
- WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
-oh-name);
- return 0;
- }
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r 0)
+ pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+oh-name);
This is the real piece that fixes the issue.
r = _init_clocks(oh, NULL);
if (r 0) {
I've tested this patch on am43x-gp-evm, and it seems to fix the issue
although with some unpleasant warning messages.
Could you paste those in?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: DRA7xx: hwmod: set DSS submodule parent hwmods
Hi Tomi, your detailed description of the problem is really great; thanks for the summary. On Mon, 5 Jan 2015, Tomi Valkeinen wrote: On 03/01/15 00:50, Paul Walmsley wrote: On Fri, 19 Dec 2014, Tomi Valkeinen wrote: Set DSS core hwmod as the parent for all the DSS submodules. This fixes the boot time DSS reset, removing the following warnings: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued for v3.19-rc. Note that I cannot test this patch due to lack of a DRA7xx board here. Thanks. Unfortunately, I made a mistake with the DRA7xx patch. Well, the patch itself is correct, but we have some insanity in the HW that I missed: DRA7xx has a CTRL_CORE_CONTROL_IO_2 register in the control module, which contains bits for various subsystems, including DCAN, PCIe, QSPI and DSS. At the moment only DCAN driver uses the register via syscon + regmap. For DSS, the bit 0, DSS_DESHDCP_CLKEN is critical. While the bit is rather undocumented, it presumably enables a clock for DSS's HDCP. Now, we don't support HDPC in the display driver, but unfortunately the clock is required for the DSS hardware to initialize. Do you know where this DSS_DESHDCP clock appears in the clock tree? Is it downstream of the main DSS functional clock, or does it come from somewhere else? Without this patch, we see only the few warnings about dss hwmods cannot be enabled, but with the patch, we see those and some WARN()s from hwmod as the DSS HW module does not start. So it's a bit worse. Why I didn't notice this is that I had an u-boot version that enables the DSS_DESHDCP_CLKEN bit and leaves it enabled. So what to do about the issue? You could drop/revert this patch if we don't see a quick solution for the DSS_DESHDCP_CLKEN. It won't fix anything as such, but lessens the boot-up spam. Sounds like the thing to do in the short term is to drop that patch from the fixes series. Then we can add it back when DSS_DESHDCP_CLKEN is sorted. Are you OK with that for the time being? I don't have a good idea how to manage the bit properly. As far as I see, the bit has to be managed via syscon, using remap_update_bits, so that we get proper locking. With a quick glance, I didn't see anything for that in the current clock code. And can we presume that syscon is probed before hwmods? I guess not. Based on the description so far, it sounds like there should be a system control module driver that registers this clock, along with all of the other clocks in the CTRL_CORE_CONTROL_IO_2 register. Just shooting from the hip here, I guess we'd probably list that DSS_DESHDCP_CLKEN clock as an optional clock for DSS in the hwmod data, and add some code to indicate that it should be enabled and disabled with the main_clk. For the time being, I think the easiest solution would be to just set the bit and leave it enabled. My understanding (based on commits in TI's product kernel) is that leaving the DSS_DESHDCP_CLKEN enabled doesn't really affect much, and any increased power consumption would be too small to measure. If that's the route, the question is still where to enable it. As I said, I have an u-boot which enables it, but I'd rather do the enabling in the kernel. If in the kernel, where there? It has to happen before the hwmod init is ran. Yeah, that's a tricky question to answer. If DSS_DESHDCP_CLKEN is modeled as a clock, then it could be marked as ENABLE_ON_INIT, but that seems like kind of a hack. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.19-rc3
Here are some basic OMAP test results for Linux v3.19-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc3/20150105224749/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 1/ 3): omap1_defconfig_1510innovator_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL ( 2/17): omap2plus_defconfig_no_pm, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.19-rc2 (b7392d2247cfe6771f95d256374f1a8e6a6f48d6)): text data bsstotal kernel +1820 -160+1804 omap1_defconfig +796 -80 +788 omap1_defconfig_1510innovator_only +796 +240 +820 omap1_defconfig_5912osk_only +10827 +4720 +11299 multi_v7_defconfig +532 +560 +588 omap2plus_defconfig +352 +720 +424 omap2plus_defconfig_2430sdp_only +468 +480 +516 omap2plus_defconfig_am33xx_only +468 +88 -64 +492 omap2plus_defconfig_am43xx_only +532 +480 +580 omap2plus_defconfig_cpupm +404 +48 -64 +388 omap2plus_defconfig_dra7xx_only -800 -8 omap2plus_defconfig_n800_multi_omap2xxx +2400 +24 omap2plus_defconfig_n800_only_a +4556 +800+4636 omap2plus_defconfig_no_pm +468 +800 +548 omap2plus_defconfig_omap2_4_only +532 +480 +580 omap2plus_defconfig_omap3_4_only +468 +80 -64 +484 omap2plus_defconfig_omap5_only -112 +32 -56 -136 rmk_omap3430_ldp_allnoconfig +668 +80 +676 rmk_omap3430_ldp_oldconfig -104 +64 -64
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
On Mon, 5 Jan 2015, Suman Anna wrote: That's right, the test was present even before 6423d6df1440, I merely made this a block. Indeed, I misread the commit. Sorry about ihat. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
+ Santosh Hi Lokesh On Mon, 5 Jan 2015, Lokesh Vutla wrote: On Saturday 03 January 2015 02:40 AM, Paul Walmsley wrote: On Thu, 18 Dec 2014, Roger Quadros wrote: On 18/12/14 17:49, Roger Quadros wrote: There are quite a few hwmods that don't have sysconfig register and so _find_mpu_rt_port(oh) will return NULL thus preventing ready state check on those modules after the module is enabled. Hmm. Any IP block that exposes registers that are accessible by the MPU should have an MPU register target port, even if there's no SYSCONFIG register. And if an IP block doesn't have registers that are accessible from the MPU, then there shouldn't be much point to waiting for the module to become ready. Looks like the real problem is the test for oh-class-sysc before the call to _init_mpu_rt_base(). That was introduced by commit 6423d6df1440 (ARM: OMAP2+: hwmod: check for module address space during init). It's not clear to me why that test was added, since _init_mpu_rt_base() doesn't do anything with oh-class-sysc or SYSCONFIG registers. This was introduced by commit 97597b962529 (ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc) Yes, you're right. I misread commit 6423d6df1440. Patch description states that there are few hwmod which doesn't have sysconfig registers and hence no need to ioremap() them in early init code. The MPU register target port code doesn't only determine whether the hwmod code should map the IP block's address space. It also determines whether or not the hwmod code needs to wait for the IP block to become ready after being enabled, so register accesses by non-hwmod code can succeed. Isn't this correct? That commit 97597b962529 is bogus. If the goal was to skip the ioremap(), then the right fix would have been to just skip the ioremap(). The existing commit also skips the call to _save_mpu_port_index(), which caused the problem that Roger's patch is trying to fix. May be a dumb question: If IP doesn't have sysconfig, is there any case that hwmod does access the register address space of that IP? Why do we need to enable MPU register target port? hwmod shouldn't touch the IP block registers if there are no SYSCONFIG, SYSSTATUS, etc. registers, and there's no IP block-specific reset code. But other code on the system (like the IP block's device driver) will, and the system needs to indicate that the IP block is ready before those accesses occur. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
Roger, Lokesh, could you try this one instead?
It passes all the basic tests here except it does not boot on the 4460
VAR-SOM-OM - unclear why at this point - but it would be good to see if it
works on your AM4372 boards, since I don't have that one.
Test logs are here:
http://www.pwsan.com/omap/testlogs/hwmod_skip_only_remap_v3.19-rc/20150105171744/
- Paul
From 4f2e13bd2181e0ebede3aabc484aa2339830748a Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Mon, 5 Jan 2015 15:49:57 -0700
Subject: [PATCH] Only skip ioremap() if IP block does not have OCP header
registers. Experimental.
---
arch/arm/mach-omap2/omap_hwmod.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..03df8833d399 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1938,6 +1938,8 @@ static int _reset(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: resetting\n, oh-name);
if (oh-class-reset) {
+ WARN(!oh-_mpu_rt_va, Attempt to call custom reset with no MPU
register target ioremapped: %s,
+oh-name);
r = oh-class-reset(oh);
} else {
if (oh-rst_lines_cnt 0) {
@@ -2358,15 +2360,19 @@ static int of_dev_hwmod_lookup(struct device_node *np,
}
/**
- * _init_mpu_rt_base - populate the virtual address for a hwmod
+ * _init_mpu_rt_base - populate the MPU port and virtual address
* @oh: struct omap_hwmod * to locate the virtual address
* @data: (unused, caller should pass NULL)
* @index: index of the reg entry iospace in device tree
* @np: struct device_node * of the IP block's device node in the DT data
*
- * Cache the virtual address used by the MPU to access this IP block's
- * registers. This address is needed early so the OCP registers that
- * are part of the device's address space can be ioremapped properly.
+ * Cache the interconnect target port and the virtual address used by
+ * the MPU to access this IP block's registers. The address is needed
+ * early so the OCP registers that are part of the device's address
+ * space can be ioremapped properly. The presence or absence of the
+ * interconnect target port also indicates whether the hwmod code
+ * should wait for the IP block to indicate readiness after it is
+ * enabled.
*
* Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
* -ENXIO on absent or invalid register target address space.
@@ -2385,6 +2391,13 @@ static int __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data,
if (oh-_int_flags _HWMOD_NO_MPU_PORT)
return -ENXIO;
+ /*
+* If there's no need for the hwmod code to read or write to
+* the IP block registers, bail out early before the ioremap()
+*/
+ if (!oh-class-sysc)
+ return 0;
+
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
@@ -2451,14 +2464,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r 0) {
- WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
-oh-name);
- return 0;
- }
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r 0)
+ pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+oh-name);
r = _init_clocks(oh, NULL);
if (r 0) {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.19-rc1
On Sun, 4 Jan 2015, Arnd Bergmann wrote: So 3.16 was by far the largest increase, almost 10x bigger than the 3.19 increase, but others are quite big as well. Do you know what happened in 3.16? It was commit 1413c03893332366e5b4d1e26f942ada25f3e82a (lockdep: Increase static allocations). - Paul commit 1413c03893332366e5b4d1e26f942ada25f3e82a Author: Sasha Levin sasha.le...@oracle.com Date: Wed Jan 8 14:21:46 2014 -0500 lockdep: Increase static allocations Fuzzing a recent kernel with a large configuration hits the static allocation limits and disables lockdep. This patch doubles the limits. Signed-off-by: Sasha Levin sasha.le...@oracle.com Signed-off-by: Peter Zijlstra pet...@infradead.org Link: http://lkml.kernel.org/r/1389208906-24338-1-git-send-email-sasha.le...@oracle.com Cc: linux-ker...@vger.kernel.org Signed-off-by: Ingo Molnar mi...@kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: hwmod fixes for v3.19-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.19-rc/omap-fixes-a for you to fetch changes up to 99d076b747455449b2eec9e37f3fb0bfdf51af32: MAINTAINERS: add maintainer for OMAP hwmod data (2015-01-02 16:24:27 -0700) - For v3.19-rc, fix some hwmod structure details for the OMAP DSS modules for DRA7xx and AM43xx. Also update the MAINTAINERS file to encourage folks to cc me on hwmod data patches. Basic build, boot, and PM testlogs are available here: http://www.pwsan.com/omap/testlogs/omap-fixes-a-for-v3.19-rc/20150103144242/ - Paul Walmsley (1): MAINTAINERS: add maintainer for OMAP hwmod data Tomi Valkeinen (2): ARM: AM43xx: hwmod: set DSS submodule parent hwmods ARM: DRA7xx: hwmod: set DSS submodule parent hwmods MAINTAINERS| 6 ++ arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++ 3 files changed, 10 insertions(+) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUqc29AAoJEMePsQ0LvSpLwHMP/iwMppVchp7aBom6wAJXf5Cf 3d6M8j+5UNex01TDnBAj9fSWC0ea/HkEKpOSVp+TOsLX1cnMPQfC6wBmJ4nZ4HLG l+7e1x6S0eKCvoMh6yvTzf5hJfmHCs0ULcJJ2E87fNhuSJ+t7ESCaVFSFqCvT2Fi Rq+9Ba/9Mwe2UHotmwRpt1wNFSzIWuHfi2La5SOwUdPZ/6snpy5blmGpipG4vUJL Oe3zvY0NVo0Ee/i8Q89UqmE56jStsq6/Lo4rH1yfVTLAnFdR43X8lC8u5uKvaQB9 EELRUvY+chISVVahHFAt2DmuenPBnYIQqZ6I4rgf+RirT7Ee2qEL4Chty5bwrz61 OfGiWEvZ/JmnVvn6SYicZ9wbKL58AL1eVMG6ylHBtjiAkJc2eg5QeS+uNnEBFjIG 6UeVLBQQ1ldvYt/n8L3vyxqeKnf4f9/THg/4hvgYLvhs2Vpj8dL2syknwhfRb1pG 7yLH7pD3wxibAK5gMVLNR8NdDZmfUeI/EyF++CqY5qj5YzN4qTUk2mvpdQI96bg0 mgPs/t1mNg54M2W6TnWLAF7CnowK3UTAu3QxmxQuaxXf5uu0mWmxyAijzl7LTeoj 6Gm/qyLALvE7cTAH/10PjkrvvP0MpZ6Fs9PWLEc3t1/6RoDXZA6BdzQARSjvhgMM Y2mY3tU2B7IUbycZQIkS =4el2 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.19-rc1
On Sat, 3 Jan 2015, Arnd Bergmann wrote: On Saturday 03 January 2015 07:21:49 Paul Walmsley wrote: Another ~300KB kernel object size increase for omap2plus_defconfig kernels. 300kb seems like a lot for a single release. +300KB is high, but not exceptionally so. The data, since I started keeping track of it, is below. The last numeric column represents the total kernel object size delta in bytes. Have you looked into where this is coming from? I have not. - Paul http://www.pwsan.com/omap/testlogs/ test_v3.7-rc1/20121017205513/build/size.txt:+128332 -67728+2144 +62748 omap2plus_defconfig test_v3.8-rc1/20121228031713/build/size.txt:+168843 +25288 +900 +195031 omap2plus_defconfig test_v3.9-rc1/20130312100243/build/size.txt:+195310 +37968+1364 +234642 omap2plus_defconfig test_v3.10-rc1/20130518212204/build/size.txt: -59854 -98552 +37136 -121270 omap2plus_defconfig test_v3.11-rc1/20130721020309/build/size.txt:+159173-2456+1680 +158397 omap2plus_defconfig test_v3.12-rc1/20130922202452/build_z/size.txt:+237402 +47344 +760 +285506 omap2plus_defconfig test_v3.13-rc1/20131208173326/build_z/size.txt:-276029-5584+5008 -276605 omap2plus_defconfig test_v3.14-rc1/20140210035354/build_z/size.txt: +94801 -17448-9016 +68337 omap2plus_defconfig test_v3.15-rc1/20140421113253/build_z/size.txt: +30722 +11392+4312 +46426 omap2plus_defconfig test_v3.16-rc1/20140629224344/build_z/size.txt:+133191 +20776 +2750728 +2904695 omap2plus_defconfig test_v3.17-rc1/20140821122707/build_z/size.txt: +54469 -34424+1728 +21773 omap2plus_defconfig test_v3.18-rc1/20141020095901/build_z/size.txt:+677950 +32008 +54408 +764366 omap2plus_defconfig test_v3.19-rc1/20150102151849/build_z/size.txt:+297698+9648-4528 +302818 omap2plus_defconfig -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
+ Suman, lakml
Hi Roger
On Thu, 18 Dec 2014, Roger Quadros wrote:
Fixing up Paul's email id.
cheers,
-roger
On 18/12/14 17:49, Roger Quadros wrote:
There are quite a few hwmods that don't have sysconfig register and so
_find_mpu_rt_port(oh) will return NULL thus preventing ready state check
on those modules after the module is enabled.
Hmm. Any IP block that exposes registers that are accessible by the MPU
should have an MPU register target port, even if there's no SYSCONFIG
register. And if an IP block doesn't have registers that are accessible
from the MPU, then there shouldn't be much point to waiting for the module
to become ready.
Looks like the real problem is the test for oh-class-sysc before the
call to _init_mpu_rt_base(). That was introduced by commit 6423d6df1440
(ARM: OMAP2+: hwmod: check for module address space during init). It's
not clear to me why that test was added, since _init_mpu_rt_base() doesn't
do anything with oh-class-sysc or SYSCONFIG registers.
Could you please test the following patch?
I don't have an AM437x-gp-evm.
- Paul
---
arch/arm/mach-omap2/omap_hwmod.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cbb908dc5cf0..ce6d11f3eda7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2451,14 +2451,10 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
oh-name, np-name);
}
- if (oh-class-sysc) {
- r = _init_mpu_rt_base(oh, NULL, index, np);
- if (r 0) {
- WARN(1, omap_hwmod: %s: doesn't have mpu register
target base\n,
-oh-name);
- return 0;
- }
- }
+ r = _init_mpu_rt_base(oh, NULL, index, np);
+ if (r 0)
+ pr_debug(omap_hwmod: %s: doesn't have mpu register target
base\n,
+oh-name);
r = _init_clocks(oh, NULL);
if (r 0) {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: DRA: hwmod: RTC: Add reset function for RTC
Ping. Are you going to redo this one? - Paul On Wed, 26 Nov 2014, Paul Walmsley wrote: Hi Lokesh On Tue, 25 Nov 2014, Lokesh Vutla wrote: Hi Paul, On Thursday 20 November 2014 10:26 PM, Paul Walmsley wrote: On Thu, 20 Nov 2014, Lokesh Vutla wrote: On Monday 17 November 2014 10:13 AM, Lokesh Vutla wrote: RTC IP have kicker feature which prevents spurious writes to its registers. In order to write into any of the RTC registers, KICK values has te be written to KICK registers. Currently hwmod is updating the IDLEMODE in rtc sysconfig register without writing into any kick register which is a noop. When autoidle is allowed for rtc, interruts are not received until IDLEMODE is set to SIDLE_SMART_WKUP. Adding a reset function to unlock RTC registers so that IDLEMODE is updated. Ping..!! Is this patch acceptable? Lokesh 1. This looks like a fix. Is this intended to go in as a v3.18-rc patch, or against v3.19? If so it would be very helpful for the maintainers if you were to state that somewhere. Yes. This is a fix, intended to go in 3.18-rc. Sorry should have mentioned it. A few questions. Do you know when this problem started (in terms of kernel versions)? Also: the patch description states that this is only a problem when autoidle is allowed for RTC. What enables autoidle for RTC - the RTCSS driver? Or does hwmod wind up doing this after the RTCSS driver unlocks it? 2. Your patch unlocks the RTC registers, but never relocks it. This seems to defeat the point of the spurious write protection. Shouldn't your patch only unlock the RTC immediately before the hwmod code touches the RTC registers, and then relock it immediately afterwards, per SPRUHZ6 section 23.4.3.3? If so then the .reset function pointer is the wrong place for this; I would suggest adding some .lock and .unlock function pointers that are to be called before and after any register write to the IP block. Yeah I agree with you. Currently rtc driver unlocks these kick registers in probe and leaves it unlocks for further use. But if hwmod does unlock and lock for every sysconfig write driver should also implement unlock and lock for every rtc register write, which adds an extra overhead. I am not sure if some one writes into rtc registers other than hwmod and driver. IMO we can leave it unlocked as the driver does. I would think that the best approach would be to set up .lock and .unlock function pointers, then add a temporary hwmod flag that, if set, would prevent the .lock function from ever being called. Then once the driver is fixed, that flag can be dropped. 3. Your macros don't mention DRA7xx specifically. Does this sequence apply to some other TI chips, or just DRA7xx? Please document this in a comment above the macros, and possibly change the name of the macros to refer to DRA7XX. This sequence applies to AM43xx and AM33xx also. So made it generic. Ill document it. OK but it would need more than just documentation, right? Wouldn't the hwmod data also need to be modified for AM33xx/AM43xx to add the .reset function pointer? Any reason why folks wouldn't have seen this problem on AM33xx/AM43xx? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: AM43xx: hwmod: set DSS submodule parent hwmods
On Fri, 19 Dec 2014, Tomi Valkeinen wrote: Set DSS core hwmod as the parent for all the DSS submodules. This fixes the boot time DSS reset, removing the following warnings: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued for v3.19-rc. Note that I cannot test this patch due to lack of a AM43xx board here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: DRA7xx: hwmod: set DSS submodule parent hwmods
On Fri, 19 Dec 2014, Tomi Valkeinen wrote: Set DSS core hwmod as the parent for all the DSS submodules. This fixes the boot time DSS reset, removing the following warnings: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued for v3.19-rc. Note that I cannot test this patch due to lack of a DRA7xx board here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.19-rc1
Here are some basic OMAP test results for Linux v3.19-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc1/20150102151849/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 2/17): 2430sdp, 2420n800 skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 skip ( 2/17): 5912osk, 3517evm Pass (12/17): am335xbonelt, am335xbone, 4460pandaes, 37xxevm, 2430sdp, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm skip ( 6/17): 5912osk, 3517evm, am335xbonelt/am335x-boneblack, am335xbone, cmt3517, 2420n800 Pass ( 4/17): 4460pandaes, 2430sdp, 5430es2uevm, 5430es2sbct54 vmlinux object size (delta in bytes from test_v3.18 (b2776bf7149bddd1f4161f14f79520f17fc1d71d)): text data bsstotal kernel +100107+3648-6248 +97507 omap1_defconfig +101103+2800-6248 +97655 omap1_defconfig_1510innovator_only +101099+2816-6184 +97731 omap1_defconfig_5912osk_only +883783 +15784-2432 +897135 multi_v7_defconfig +297698+9648-4528 +302818 omap2plus_defconfig +280493 +10720-1824 +289389 omap2plus_defconfig_2430sdp_only +297806 +10696-4592 +303910 omap2plus_defconfig_am33xx_only +327814 +11784-4400 +335198 omap2plus_defconfig_am43xx_only +293602+9664-4528 +298738 omap2plus_defconfig_cpupm +324078 +12384-4400 +332062 omap2plus_defconfig_dra7xx_only +216837+8480-4600 +220717 omap2plus_defconfig_n800_multi_omap2xxx +213429+8432-4632 +217229 omap2plus_defconfig_n800_only_a +291026+9864-4656 +296234 omap2plus_defconfig_no_pm +330978 +11696-4464 +338210 omap2plus_defconfig_omap2_4_only +315374+7280-4528 +318126 omap2plus_defconfig_omap3_4_only +327978 +11464-4400 +335042
OMAP baseline test results for v3.19-rc2
Here are some basic OMAP test results for Linux v3.19-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.19-rc2/20150102204752/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 skip ( 2/17): 5912osk, 3517evm Pass (12/17): am335xbonelt, am335xbone, 4460pandaes, 37xxevm, 2430sdp, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during PM test: FAIL ( 7/17): 4430es2panda, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm skip ( 6/17): 5912osk, 3517evm, am335xbonelt/am335x-boneblack, am335xbone, cmt3517, 2420n800 Pass ( 4/17): 4460pandaes, 2430sdp, 5430es2uevm, 5430es2sbct54 vmlinux object size (delta in bytes from test_v3.19-rc1 (97bf6af1f928216fd6c5a66e8a57bfa95a659672)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0 -80 -8 omap1_defconfig_5912osk_only +1264 -240+1240 multi_v7_defconfig -11600 -116 omap2plus_defconfig -8400 -84 omap2plus_defconfig_2430sdp_only -5200 -52 omap2plus_defconfig_am33xx_only -11600 -116 omap2plus_defconfig_am43xx_only -11600 -116 omap2plus_defconfig_cpupm -5200 -52 omap2plus_defconfig_dra7xx_only 0000 omap2plus_defconfig_n800_multi_omap2xxx -299426 -22760 -12120 -334306 omap2plus_defconfig_n800_only_a -5200 -52 omap2plus_defconfig_no_pm -5200 -52 omap2plus_defconfig_omap2_4_only -5200 -52 omap2plus_defconfig_omap3_4_only -5200
Re: regression: Clock changes in next-20141205 break at least omap4
On Wed, 17 Dec 2014, Tero Kristo wrote: The dual parent issue required by the DPLL code is caused by the introduction of determine-rate / set-parent / set-rate-and-parent logic to OMAP DPPLs. I took a short-cut here, making the assumption that every DPLL has both of these clocks defined (which basically they do have, as every DPLL technically has both reference and bypass clocks, but which can be the same clock = thus the declaration itself is missing in some cases.) The clock data is modelled like this for every other TI SoC (which use DT clock data), except for omap3 legacy clock data, thus the patch to tweak the clock data itself. It would be much harder to modify the clock code itself to take this into account, rather than just add the missing parents to the clock data, thus the approach taken in the patch. We can of course discuss whether it is okay to have DPLLs modelled as they are right now. I think them as composite clocks containing mux, gate and divider/multiplier logic within a single black box, we could split them up, but I don't see much need for that. If it works, don't break it. Regarding the omap3 clock data patch, I have also just posted new patch set that will move the omap3 legacy clock data under clock driver, until we figure out what to finally do with this (use the DT clocks, or introduce loadable clock data modules or something.) Thus, the data patch is kind of a temporary one, or thats the intention at least, but I wouldn't call it a hack. It is there to fix the issues introduced by the set-parent / set-rate-and-parent logic, which was required by the changes to the core clock set-rate. OK, I understand now why the OMAP3 clock DT data takes two of the same clock - one is for the reference and one is for bypass. So I retract my earlier statement about it being a hack, and am fine with Tero's original patch. I suppose I should resuscitate the uImage booter for the OMAP3 boards here at least. I dropped those out of the testbed thinking that we'd switch over to DT-only fairly quickly; that turned out not to be the case. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: add the omap-pending tree
Hi Stephen, Might you be willing to include this branch in your linux-next builds? git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git#for-next It will include OMAP clock, bus architecture, and low-level power management patches that are planned to be included in pull requests to the OMAP upstream maintainer, Tony Lindgren. He in turn will submit pull requests to the arm-soc tree. The objective in including this branch is to get these patches integration-tested earlier than they would be otherwise. regards, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
On Wed, 17 Dec 2014, Lucas Stach wrote: Maybe I'm thinking about this too lightly, but I think we already have the right abstractions in place. The clock tree in Linux is always modeled along the flow of reference clocks. So typically the root of the tree is something like an oscillator and everything spreads out from this in a parent/child relation. So clearly the reference clock of a PLL is the PLLs parent. If the PLL is running in open-loop mode (isn't this rather direct frequency synthesis?) is has no parent and is the root of a tree itself. If a PLL needs a functional clock to drive some internal logic, that doesn't directly influence the clock synthesis from reference to resulting clock, that clock would be no parent to the PLL. The PLL is merely a consumer of this clock just like every other device in the system. I suspect we're using different terminology. From my point of view, a reference clock is an input clock signal that is used by another clock generator IP block or clock measurement IP block. The use is to measure and (optionally) discipline another oscillator. Thus the clock generator/measurement IP block generally does not electrically propagate the reference clock outside of the block. (Although some of the reference clock's characteristics, like phase noise or frequency stability, may be propagated indirectly.) Only a small number of clock tree entities makes use of reference clocks. By contrast, we could use the term source clock in the SoC context to mean a clock signal that directly drives a downstream IP block, in an electrical sense. These clocks are directly propagated through dividers and muxes. If you're willing to play along with this terminology, then a PLL's source clock would be its internal VCO/DCO, which thus would be the root clock of the PLL. Flipping over from hardware to software, in the Linux clock tree, there's usually not much point to modeling the VCO/DCO directly because it tends not to be under the direct control of the OS, and it is usually tightly integrated into the PLLs from a hardware point of view. But unlike most of the Linux clock tree nodes that are downstream from clock sources, which use clocks that are electrically driven by the clock source, the clock signal that PLLs and PLL-like clocks generate is not directly driven by the reference clock. So why is a reference clock listed as a Linux parent clock of an OMAP PLL? At least for OMAP, it was sort of shoehorned in to represent a gating dependency. It was a way of stating that the reference clock had to be enabled for the PLL to generate an output clock. (The off-chip crystal oscillator that drives most of the PLL reference clocks could be disabled when all of its users were idle, to save energy.) But this type of gating dependency is equally true for, say, a separate functional clock that the clock source requires in order to operate. (OMAP PLLs didn't have a separate functional clock, at least not that I was aware of; but that's not true for some similar clock sources used in other SoCs.) The clock framework wasn't re-entrant back then, and we wanted to avoid implementing re-entrancy because we were worried that it could turn into a mess. So we just wound up listing the reference clock as the PLL's Linux parent clock. My original comment was just intended to be a reflection on what it means to be a parent clock in the Linux clock tree sense. If it's intended to represent source clocks as they are defined above, then PLLs and PLL-like clocks should be root nodes, except for the few cases where it's useful to add a node for the underlying source oscillator directly (for example, if open-loop mode is supported). This might be the right way forward for the time being, and I like the idea of stating that Linux parent clocks should represent electrical source clock relationships. That raises the question of what to do about the additional gating relationships. At the moment, the clock type code needs to be responsible for calling clk_enable() etc. on all of the reference and functional clocks that need to be ungated for the clock source to work. But it has always seemed preferable to me to represent fundamental hardware structural constraints in data. If the data structures are well-defined, then the data should be relatively easy to analyze, reason about, generate, validate, share across platforms, and operate upon iteratively; unlike custom per-clocktype code, which often isn't. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
On Thu, 18 Dec 2014, Mike Turquette wrote: Quoting Paul Walmsley (2014-12-18 11:23:07) Flipping over from hardware to software, in the Linux clock tree, there's usually not much point to modeling the VCO/DCO directly because it tends not to be under the direct control of the OS, and it is usually tightly integrated into the PLLs from a hardware point of view. But unlike most of the Linux clock tree nodes that are downstream from clock sources, which use clocks that are electrically driven by the clock source, the clock signal that PLLs and PLL-like clocks generate is not directly driven by the reference clock. Hi Paul, Hi Mike, This is debatable given that the formula to determine the OMAP DPLL output rate directly depends upon the rate of the input clock (osc, 32Khz, hsd, bypass, etc). I'm not speaking for all PLLs, just for the OMAP ones that I am familiar with. The frequency and phase noise characteristics of the PLL's output signal are partially a function of the reference clock. But that's only because the reference clock is used to steer the VCO. It's not because the reference clock itself appears on the PLL output. Even if the reference clock dividers and VCO loop dividers were both set to divide-by-one, the reference clock still would not appear on the PLL output - merely a simulacrum of it, originating by the VCO. The PLL's output clock is, electrically, directly driven by the VCO. Page 5 of this PDF has a nice frequency synthesis PLL block diagram with integer dividers: http://www.ti.com/lit/an/swra029/swra029.pdf To rephrase, if, in the block diagram above, one were to remove everything from the TCXO reference clock on the left to the triangle to the left of the VCO, and to replace all that with a constant voltage input to the VCO, you'd still get a clock signal out of the IP block, even though the reference clock would no longer exist. So why is a reference clock listed as a Linux parent clock of an OMAP PLL? At least for OMAP, it was sort of shoehorned in to represent a gating dependency. It was a way of stating that the reference clock had to be enabled for the PLL to generate an output clock. (The off-chip crystal oscillator that drives most of the PLL reference clocks could be disabled when all of its users were idle, to save energy.) But this type of gating dependency is equally true for, say, a separate functional clock that the clock source requires in order to operate. (OMAP PLLs didn't have a separate functional clock, at least not that I was aware of; but that's not true for some similar clock sources used in other SoCs.) Using your terminology above, it is possible to do what you want to do today without any change to the clock framework. Simply make each DPLL a device. That device calls clk_get, clk_prepare_enable on the input reference clock. I think I did something like that with the Tegra DFLL driver last year. Except the clock provider device was the DFLL IP block itself, with its own registers, etc., and not an additional abstraction, if I recall correctly. My interest is mostly to determine whether some of that special-case code can be converted into data that the CCF core can operate on, in a consistent manner that would be useful across platforms, and in a way that several people could potentially agree on. Coincidentally these new DPLL device are clock providers themselves and they provide root clocks of their own which are the DPLLs and corresponding Mx outputs. This model would treat the reference clock as something that drives the DPLL device's logic, but not as a part of the clock signal chain. I don't personally agree with the idea that the reference clock is not a parent of the DPLL, I'd be interested to know how you would define a parent clock, if it differs from the electrical source clock definition that I mentioned. The Linux clock tree is a software abstraction. So one could define parent clock however one wishes. (That's not to say that all definitions are equally useful...) One could state, for example, that a parent clock is any clock that has some effect on the output of the child clock. That would be one definition which might be consistent with your comments. The problem with that is that it means that a clock can have multiple simultaneously-active parents, which I'd naïvely think we'd want to avoid, if we could. I also have to admit that my bias is towards definitions with some kind of relationship to the hardware, which helps avoid the utter relativism problem that you mention below. but I don't oppose any change to the OMAP clock driver along those lines so long as it is done in a sane way. It seems there is never just one correct way to look at these things. I'd say that to the extent that one could come up with concrete definitions for terms like parent clocks, it allows others to reason about how
Re: regression: Clock changes in next-20141205 break at least omap4
+ Tero
On 12/16/2014 12:01 PM, Stephen Boyd wrote:
On 12/15/2014 05:31 PM, Paul Walmsley wrote:
I just took a quick glance at Tero's second patch, and it looks like a
hack to me. Better to fix the problem in the core CCF code if
possible. I don't think there's any reason why a PLL couldn't have
just one parent clock. But I'm fine with merging it as a short-term
fix if fixing the core code is difficult or risky.
Can you describe what's wrong?
Took a closer look at it, at your prompting.
The first observation is that the issue seems to be limited to
TI-specific clock code in drivers/clk/ti. So nothing to worry about in
terms of the CCF core, it looks.
The second observation is that this appears to only be a problem due to
the current DT data in arch/arm/boot/dts/omap3xxx-clocks.dtsi:
dpll3_ck: dpll3_ck {
#clock-cells = 0;
compatible = ti,omap3-dpll-core-clock;
clocks = sys_ck, sys_ck;
reg = 0x0d00, 0x0d20, 0x0d40, 0x0d30;
};
It lists two entries for the clocks node for some reason.
of_ti_dpll_setup() only seems to require one.
So unless there's some good reason to list two of them in the DTS file,
the right fix would probably have been to fix the DT data.
Does the PLL have a mux with two inputs that map to the same clock?
I don't think so.
...
Generally speaking, I suspect the way we model PLLs isn't quite right
(although it's been a while since I've looked at that particular code).
This was probably my fault, in the final analysis, for taking a shortcut
here a long time ago.
Unless one wishes to implement support for multiple clock parents, it's
probably not quite right to state that a PLL's reference clock is a
parent in a clock tree sense. When a PLL is active, the output clock
originates from a VCO of some kind that is internal to the PLL. The
reference clock is just used by the PLL internal logic to close the
control loop. Some PLL-like clock sources use a third clock that is
used to clock some of the PLL's internal logic (let's call this a
functional clock.)
So the reference clock and functional clock are (usually) required by
the PLL to operate, and should therefore be required by the PLL clock
driver code in the kernel; but one could claim that they aren't
technically parent clocks of the PLL in a clock tree sense, since the
downstream output clock isn't directly derived from either of those clocks.
Otherwise if we want to represent those clocks accurately in the Linux
clock tree, we probably need to state that clocks can have multiple
parents that often need to be active simultaneously, and we should
propagate usecount changes accordingly up all of the parent paths.
...
Anyway, thanks for following up on this,
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
On Tue, 16 Dec 2014, Russell King - ARM Linux wrote: On Tue, Dec 16, 2014 at 01:01:17PM -0700, Paul Walmsley wrote: So the reference clock and functional clock are (usually) required by the PLL to operate, and should therefore be required by the PLL clock driver code in the kernel; but one could claim that they aren't technically parent clocks of the PLL in a clock tree sense, since the downstream output clock isn't directly derived from either of those clocks. The reference clock is the parent clock for a PLL, and the output clock is a derivative of the reference clock. The PLL maths show that very clearly. The PLL's internal oscillator is the electrical source of the PLL's output clock. The reference clock is just used to discipline that internal oscillator. Even that's not necessary - the reference clock can be optional on some clock source implementations, which can run the internal oscillator in open-loop mode. The question of what the appropriate parent clock(s) should be is really a question of how the software chooses to model it, and has more to do with use-counts, constraints, etc. I don't believe we have documented a precise definition for what a parent clock is, in the Linux clock framework context. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
+ p...@pwsan.com (I prefer not having to deal with MS Exchange when possible :-) ) On Tue, 16 Dec 2014, Russell King - ARM Linux wrote: On Tue, Dec 16, 2014 at 08:45:25PM +, Paul Walmsley wrote: On Tue, 16 Dec 2014, Russell King - ARM Linux wrote: On Tue, Dec 16, 2014 at 01:01:17PM -0700, Paul Walmsley wrote: So the reference clock and functional clock are (usually) required by the PLL to operate, and should therefore be required by the PLL clock driver code in the kernel; but one could claim that they aren't technically parent clocks of the PLL in a clock tree sense, since the downstream output clock isn't directly derived from either of those clocks. The reference clock is the parent clock for a PLL, and the output clock is a derivative of the reference clock. The PLL maths show that very clearly. The PLL's internal oscillator is the electrical source of the PLL's output clock. The reference clock is just used to discipline that internal oscillator. Even that's not necessary - the reference clock can be optional on some clock source implementations, which can run the internal oscillator in open-loop mode. I would argue that running a PLL in open-loop mode is an exceptional circumstance: in such scenarios, many PLLs will head towards a certain frequency (depending on their design) and some may be rather unstable in open loop mode. Only those which have been explicitly designed to be stable in open loop mode should be run that way. And arguably, a PLL without a reference clock is not a phase *locked* loop at all - the clue is in the name. A PLL without a reference clock is merely an oscillator. There is no phase lock what so ever. ... This really is a question about how you view a PLL, and it's one which can be debated for a very long time, and everyone will have perfectly valid but conflicting ideas on it. Yep, I agree with most of what you wrote. I was mostly thinking about our Linux data structures and software abstraction for clocks that have multiple input clocks that all need to be simultaneously active for the IP block to work. PLLs and PLL-like clock sources which take multiple input clocks just happened to be the examples of this phenomenon that came to mind. Those multiple input clocks could all be considered parents from a use-counting point of view, and we could expect the core clock code to deal with them. Or one could take the electrical point of view and consider only one of the input clocks to be the parent -- whatever's directly driving the output clock -- and fix up the gating and constraint details in the driver code for that clock source. I don't think this pot is boiling over at the moment; but, just something for us to reflect on. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
On 12/15/2014 03:02 PM, Mike Turquette wrote: Quoting Paul Walmsley (2014-12-12 15:28:32) On Fri, 12 Dec 2014, Mike Turquette wrote: Quoting Tony Lindgren (2014-12-05 10:38:49) * Stephen Boyd sb...@codeaurora.org [141205 10:23]: On 12/05/2014 08:55 AM, Tony Lindgren wrote: Hi, Looks like commit 646cafc6aa4d (clk: Change clk_ops-determine_rate to return a clk_hw as the best parent) breaks booting at least for omap4. Do you get a compilation warning in arch/arm/mach-omap2/dpll3xxx.c ? Yes so it seems. From what I can tell omap3_noncore_dpll_determine_rate() hasn't been updated to take a clk_hw pointer instead of clk pointer. It was there in the original patch and I'm not sure why Mike dropped that part while applying. OK that makes sense, Mike should apply that part too. Note that also include/linux/clk/ti.h needs changed accordingly for struct clk_hw, which you probably had in your orignal patch too. Assuming that's there, please feel free to add: Acked-by: Tony Lindgren t...@atomide.com I figured out what went wrong here. When I applied Tomeu's changes the OMAP stuff did not apply at all. In fact the .determine_rate callbacks did not exist in clk-next. Paul merged that stuff through his tree[0]. I don't know why I didn't follow up on that at the time. So we need to come up with a solution. Paul can take the OMAP portion of Tomeu's changes[1] for OMAP, but I believe compilation will be broken in his tree until it meets up with mine in linux-next. Or we could set up a shared immutable branch that provides the needed changes. I could either set up a shared branch that includes Tomeu's changes that Paul could merge (will require a rebase of the tip of my tree) or Paul could provide a shared branch of the changes to dpll3xxx.c and dpll4xxx.c that I could merge in. Or I could remove Tomeu's patches from my tree since we're right up against the merge window but I would rather not do that since he has worked tirelessly on this topic. [0] http://www.spinics.net/lists/arm-kernel/msg377288.html [1] https://lkml.org/lkml/2014/12/2/70 I don't think there's much that I can do at this point. My tree is quite topologically distant from Linus's tree (pjw/omap-pending - tmlind/linux-omap - arm/arm-soc - torvalds/linux). So anything I do is high-latency. My pull request for Tero's patches was sent to Tony a month ago. Paul, I identified the patch in your tree that is missing in mine and, with Tony's help, applied your for-v3.19/omap-a signed tag to my tree. With these 5 patches in place I have applied Tero's two patches from Friday[0]. Paul Tony, are you OK for me to take both of Tero's patches? I'm already taking stuff in late so it is no trouble for me to pick up ARM: OMAP3: clock: fix boot breakage in legacy mode while I'm at it. I'm going to let this get at least one cycle in linux-next before sending my PR late this week. Hopefully Kevin (Cc'd) can check on the omap boards in his autobuilder once my tree hits -next? Let me know if I missed anything. Thanks for the great teamwork, gang. [0] http://lkml.kernel.org/r/1418390521-7541-1-git-send-email-t-kri...@ti.com Regards, Mike I think Tony's taking the second patch from Tero. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
On 12/15/2014 05:38 PM, Tony Lindgren wrote: * Paul Walmsley pwalms...@nvidia.com [141215 16:23]: On 12/15/2014 03:02 PM, Mike Turquette wrote: Quoting Paul Walmsley (2014-12-12 15:28:32) On Fri, 12 Dec 2014, Mike Turquette wrote: Quoting Tony Lindgren (2014-12-05 10:38:49) * Stephen Boyd sb...@codeaurora.org [141205 10:23]: On 12/05/2014 08:55 AM, Tony Lindgren wrote: Hi, Looks like commit 646cafc6aa4d (clk: Change clk_ops-determine_rate to return a clk_hw as the best parent) breaks booting at least for omap4. Do you get a compilation warning in arch/arm/mach-omap2/dpll3xxx.c ? Yes so it seems. From what I can tell omap3_noncore_dpll_determine_rate() hasn't been updated to take a clk_hw pointer instead of clk pointer. It was there in the original patch and I'm not sure why Mike dropped that part while applying. OK that makes sense, Mike should apply that part too. Note that also include/linux/clk/ti.h needs changed accordingly for struct clk_hw, which you probably had in your orignal patch too. Assuming that's there, please feel free to add: Acked-by: Tony Lindgren t...@atomide.com I figured out what went wrong here. When I applied Tomeu's changes the OMAP stuff did not apply at all. In fact the .determine_rate callbacks did not exist in clk-next. Paul merged that stuff through his tree[0]. I don't know why I didn't follow up on that at the time. So we need to come up with a solution. Paul can take the OMAP portion of Tomeu's changes[1] for OMAP, but I believe compilation will be broken in his tree until it meets up with mine in linux-next. Or we could set up a shared immutable branch that provides the needed changes. I could either set up a shared branch that includes Tomeu's changes that Paul could merge (will require a rebase of the tip of my tree) or Paul could provide a shared branch of the changes to dpll3xxx.c and dpll4xxx.c that I could merge in. Or I could remove Tomeu's patches from my tree since we're right up against the merge window but I would rather not do that since he has worked tirelessly on this topic. [0] http://www.spinics.net/lists/arm-kernel/msg377288.html [1] https://lkml.org/lkml/2014/12/2/70 I don't think there's much that I can do at this point. My tree is quite topologically distant from Linus's tree (pjw/omap-pending - tmlind/linux-omap - arm/arm-soc - torvalds/linux). So anything I do is high-latency. My pull request for Tero's patches was sent to Tony a month ago. Paul, I identified the patch in your tree that is missing in mine and, with Tony's help, applied your for-v3.19/omap-a signed tag to my tree. With these 5 patches in place I have applied Tero's two patches from Friday[0]. Paul Tony, are you OK for me to take both of Tero's patches? I'm already taking stuff in late so it is no trouble for me to pick up ARM: OMAP3: clock: fix boot breakage in legacy mode while I'm at it. I'm going to let this get at least one cycle in linux-next before sending my PR late this week. Hopefully Kevin (Cc'd) can check on the omap boards in his autobuilder once my tree hits -next? Let me know if I missed anything. Thanks for the great teamwork, gang. [0] http://lkml.kernel.org/r/1418390521-7541-1-git-send-email-t-kri...@ti.com Regards, Mike I think Tony's taking the second patch from Tero. If it applies to what Mike has now queued, please take that too Mike: Acked-by: Tony Lindgren t...@atomide.com I just took a quick glance at Tero's second patch, and it looks like a hack to me. Better to fix the problem in the core CCF code if possible. I don't think there's any reason why a PLL couldn't have just one parent clock. But I'm fine with merging it as a short-term fix if fixing the core code is difficult or risky. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.18
Here are some basic OMAP test results for Linux v3.18. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18/20141208144211/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.18-rc7 (009d0431c3914de64666bec0d350e54fdd59df6a)): text data bsstotal kernel -700 -7 omap1_defconfig +5700 +57 omap1_defconfig_1510innovator_only -700 -7 omap1_defconfig_5912osk_only -87 -80 -95 multi_v7_defconfig -59 -80 -67 omap2plus_defconfig -91 -160 -107 omap2plus_defconfig_2430sdp_only -123 -80 -131 omap2plus_defconfig_am33xx_only -63 -160 -79 omap2plus_defconfig_am43xx_only -59 +160 -43 omap2plus_defconfig_cpupm -127 -80 -135 omap2plus_defconfig_dra7xx_only -67 -160 -83 omap2plus_defconfig_n800_multi_omap2xxx -35 -160 -51 omap2plus_defconfig_n800_only_a -123 +240 -99 omap2plus_defconfig_no_pm -59 +160 -43 omap2plus_defconfig_omap2_4_only -123 -160 -139 omap2plus_defconfig_omap3_4_only -63 -160 -79 omap2plus_defconfig_omap5_only -132 -16 +16 -132 rmk_omap3430_ldp_allnoconfig -103 +80 -95 rmk_omap3430_ldp_oldconfig -132 -12 +16 -128 rmk_omap4430_sdp_allnoconfig +3993 +80+4001 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.18-rc7 (009d0431c3914de64666bec0d350e54fdd59df6a)) avail rsrvd high freed board kconfig (no differences) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.18-rc7
Hi Igor, On Wed, 3 Dec 2014, Igor Grinberg wrote: On 12/02/14 20:39, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.18-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18-rc7/20141201203859/ [...] Boot to userspace: FAIL ( 1/16): 2430sdp skip ( 2/16): 5912osk, 3517evm Pass (13/16): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, 5430es2uevm, 5430es2sbct54, 2420n800 I've looked at the boot log and it seems cm-t3517 is booting just fine... Thanks for the note. I will look into this - CM-T3517 should be listed there. A problem with the test/report collecting script? Most likely... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.18-rc7
Hi Igor, On Wed, 3 Dec 2014, Paul Walmsley wrote: On Wed, 3 Dec 2014, Igor Grinberg wrote: I've looked at the boot log and it seems cm-t3517 is booting just fine... Thanks for the note. I will look into this - CM-T3517 should be listed there. A problem with the test/report collecting script? Most likely... Well this one turned out to be due to my own stupidity. It's been fixed and this particular issue should not recur. I've reuploaded a new test summary and will reply appropriately to the original message. Thanks again for pointing it out, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.18-rc7 (corrected)
Here are some basic OMAP test results for Linux v3.18-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18-rc7/20141201203859/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.18-rc6 (5d01410fe4d92081f349b013a2e7a95429e4f2c9)): text data bsstotal kernel +100 +3360 +436 omap1_defconfig -956 +3360 -620 omap1_defconfig_1510innovator_only -892 +3280 -564 omap1_defconfig_5912osk_only -303 +4560 +153 multi_v7_defconfig -59 +7440 +685 omap2plus_defconfig -863 +4880 -375 omap2plus_defconfig_2430sdp_only -4095 +7360-3359 omap2plus_defconfig_am33xx_only +5 +7440 +749 omap2plus_defconfig_am43xx_only -59 +7760 +717 omap2plus_defconfig_cpupm +5 +7360 +741 omap2plus_defconfig_dra7xx_only -255 +4880 +233 omap2plus_defconfig_n800_multi_omap2xxx -287 +4560 +169 omap2plus_defconfig_n800_only_a +145 +7680 +913 omap2plus_defconfig_no_pm +5 +7760 +781 omap2plus_defconfig_omap2_4_only +1 +7440 +745 omap2plus_defconfig_omap3_4_only -59 +7120 +653 omap2plus_defconfig_omap5_only -172 +264 +64 +156 rmk_omap3430_ldp_allnoconfig +21 +4560 +477 rmk_omap3430_ldp_oldconfig -124 +292 +48 +216 rmk_omap4430_sdp_allnoconfig -4007 +6480-3359 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.18-rc6 (5d01410fe4d92081f349b013a2e7a95429e4f2c9)) avail rsrvd high freed board kconfig -4k 4k . . 2430sdpomap2plus_defconfig -4k 4k . . 3730beaglexm omap2plus_defconfig -4k 4k . . 3730es12beaglexmomap2plus_defconfig 8k-8k .-4k am335xbone
OMAP baseline test results for v3.18-rc7
Here are some basic OMAP test results for Linux v3.18-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.18-rc7/20141201203859/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/16): 2430sdp skip ( 2/16): 5912osk, 3517evm Pass (13/16): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, 5430es2uevm, 5430es2sbct54, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.18-rc6 (5d01410fe4d92081f349b013a2e7a95429e4f2c9)): text data bsstotal kernel +100 +3360 +436 omap1_defconfig -956 +3360 -620 omap1_defconfig_1510innovator_only -892 +3280 -564 omap1_defconfig_5912osk_only -303 +4560 +153 multi_v7_defconfig -59 +7440 +685 omap2plus_defconfig -863 +4880 -375 omap2plus_defconfig_2430sdp_only -4095 +7360-3359 omap2plus_defconfig_am33xx_only +5 +7440 +749 omap2plus_defconfig_am43xx_only -59 +7760 +717 omap2plus_defconfig_cpupm +5 +7360 +741 omap2plus_defconfig_dra7xx_only -255 +4880 +233 omap2plus_defconfig_n800_multi_omap2xxx -287 +4560 +169 omap2plus_defconfig_n800_only_a +145 +7680 +913 omap2plus_defconfig_no_pm +5 +7760 +781 omap2plus_defconfig_omap2_4_only +1 +7440 +745 omap2plus_defconfig_omap3_4_only -59 +7120 +653 omap2plus_defconfig_omap5_only -172 +264 +64 +156 rmk_omap3430_ldp_allnoconfig +21 +4560 +477 rmk_omap3430_ldp_oldconfig -124 +292 +48 +216 rmk_omap4430_sdp_allnoconfig -4007 +6480-3359 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.18-rc6 (5d01410fe4d92081f349b013a2e7a95429e4f2c9)) avail rsrvd high freed board kconfig -4k 4k . . 2430sdpomap2plus_defconfig -4k 4k . . 3730beaglexm omap2plus_defconfig -4k 4k . . 3730es12beaglexmomap2plus_defconfig 8k-8k .-4k am335xbone
