Re: [PATCH] ARM: OMAP: DRA7: hwmod: Add data for McASP3
On Wed, 11 Nov 2015, Peter Ujfalusi wrote: > On 11/11/2015 07:07 PM, Felipe Balbi wrote: > > From: Peter Ujfalusi > > > > McASP3 is used by default on DRA7x based boards for audio. > > While this patch works, it is not the correct one(s) to apply. > https://lkml.org/lkml/2015/10/30/91 > is the series which should have been applied to 4.4. > Paul acked the series, but for some reason it missed the initial ARM pull for > 4.4 It missed it because I was late getting my patches out for 4.4... - 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.3-rc7
Here are some basic OMAP test results for Linux v4.3-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc7/20151025181941/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc6 (7379047d5585187d1288486d4627873170d0005a)): text data bsstotal kernel +606 +64 +32 +702 omap1_defconfig +606 +32 +32 +670 omap1_defconfig_1510innovator_only +606 +64 +32 +702 omap1_defconfig_5912osk_only +52800 +528 multi_v7_defconfig +868 +640 +932 omap2plus_defconfig +436 +32 +32 +500 omap2plus_defconfig_2430sdp_only +868 +640 +932 omap2plus_defconfig_am33xx_only +868 +640 +932 omap2plus_defconfig_am43xx_only +928 +64 +64+1056 omap2plus_defconfig_cpupm +868 +640 +932 omap2plus_defconfig_dra7xx_only +452 -32 +16 +436 omap2plus_defconfig_n800_multi_omap2xxx +608 +32 +16 +656 omap2plus_defconfig_n800_only_a +932 +960+1028 omap2plus_defconfig_no_pm +860 +72 +64 +996 omap2plus_defconfig_omap2_4_only +868
Re: [PATCH v3 0/3] ARM: OMAP2+ McASP(3) support for DRA7xx family
Hi Péter On Fri, 30 Oct 2015, Peter Ujfalusi wrote: > Changes since v2: > - DTS patch added which is needed because of the clock handling changes > > Felip Balbi reported that linux-next is broken right now since the DTS part of > the earlier series has been applied, but we do not have the mcasp hwmod in the > kernel: > ... > [0.181029] platform 48468000.mcasp: Cannot lookup hwmod 'mcasp3' > ... > [6.121072] davinci-mcasp 48468000.mcasp: _od_fail_runtime_resume: FIXME: > missing hwmod/omap_dev info > [6.130790] [ cut here ] > [6.135643] WARNING: CPU: 0 PID: 244 at drivers/bus/omap_l3_noc.c:147 > l3_interrupt_handler+0x220/0x34c() > [6.145576] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 > (Read): Data Access in User mode during Functional access > ... > > This is the followup series for the hwmod changes needed to get audio working > on DRA7xx family based boards. > The DTS patches has been applied by Tony from the original series: > http://www.spinics.net/lists/linux-omap/msg121473.html > > I have addressed your comments in the hwmod data and did some research also > regarding to the use of ahclkx as fclk in the original submission. > It turned out that McASP _needs_ all clocks to be enabled (fclk, iclk and > ahclkx/r) to be able to access registers. The original patch where we handled > the ahclkx as fclk worked, because the fclk clock got enabled in the HW w/o > any SW interaction. > All in all, the McASP found in DRA7 needs all clocks to be enabled. > To satisfy this I have introduced a new flag to hwmod, which means that the > listed optional clocks need to be handled alongside with the fclk clock. Thanks. I'm happy with your series and appreciate the indepth investigation. As you probably saw last week, we've hit the limit for v4.4-rc1: http://marc.info/?l=linux-omap&m=144564929721826&w=2 This is why I haven't done anything with this series at this time. Unfortunately I don't have a DRA7xx board, so I can't do any testing. But if this series fixes a problem with DRA7xx in linux-next, we should definitely merge it. Tony, if you want to take this now, you can either take it with my ack, or I can send a pull request. Or, if you'd prefer to take it for v4.4-rc2, I can send a pull request after v4.4-rc1. - Paul
Re: [PATCH 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data
Hi Franklin, On Mon, 26 Oct 2015, Franklin S Cooper Jr. wrote: > On 10/23/2015 02:00 PM, Paul Walmsley wrote: > > On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote: > > > >> ELM address information is provided by device tree. No longer need > >> to include this information within hwmod. > >> > >> Signed-off-by: Franklin S Cooper Jr > > The OMAP4 DTS files don't have the ELM address space declared. I'm going > > to drop that portion of your patch. Could you please send a two-patch > > series that first adds the ELM address space to the OMAP4 DTS file and > > then subsequently drops it from the OMAP4 hwmod data file? > Hi Paul, > > Sorry about that. I can create the patches but I don't see any board omap4 > board that has nand support. So I'm not going to be able to test to insure if > omap_elm.c will work as is. > > Should I just drop omap4 from this patchset or should I just add the elm node > to omap4.dtsi and if people report an issue with omap_elm then we can fix it? Please write the OMAP4 patches since we're trying to get the data cleaned up. You don't need to worry about the DRA7/335x/437x platforms; those patches have already been merged. The ELM hwmod should be initialized even on boards without NAND, so that should be a reasonable test of the register address space, at least. Please note in the patch description whether your patches are untested, tested just to initialize/boot, or whether they've been tested on an active NAND flash workload. thanks - 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+: hwmod cleanup for v4.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46: Linux 4.3-rc4 (2015-10-04 16:57:17 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.4/omap-hwmod-cleanup-a for you to fetch changes up to c4384a97af852121f66e52ba96e98d6f13ad19eb: ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs (2015-10-23 13:01:25 -0600) - ARM: OMAP2+: hwmod cleanup for v4.4 Remove some superfluous data from the OMAP2+ hwmod data files. Mostly this is a result of data being moved to DT files. Nothing too controversial, here. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/hwmod-cleanup-a-for-v4.4/20151023130140/ - Franklin S Cooper Jr (2): ARM: DRA7/AM335x/AM437x: hwmod: Remove elm address space from hwmod data ARM: DRA7/AM335x/AM437x: hwmod: Remove gpmc address space from hwmod data Javier Martinez Canillas (1): ARM: OMAP: Remove duplicated operand in OR operation Suman Anna (3): ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs ARM: DRA7: hwmod data: Remove spinlock hwmod addrs ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs .../omap_hwmod_33xx_43xx_interconnect_data.c | 20 --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 3 +-- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 -- 5 files changed, 1 insertion(+), 91 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWKpEYAAoJEMePsQ0LvSpLYf0P/3TFvwtzWalFbYbNdvBZ67q2 MLuA/cow3OXOsvVLwPKtfn60Z/wW4u/juUFpuL/1zTmcoFOiQe9Sx1FpI8W1YqXY zAbRLqbkHip/QUsAEEMjDqbQwWacNmpwChG1tCn7Ji9govi/oP3lYa+GzRXPyone NqhpwW7cV/OjgoKR8yxFEkdGdZT3I3EO2s0SyULJ+zYvrOSGHwX5SKNhh5Nd6iQV NbkiHuGospSoY9GHDHESaqabgto4l2XALN5N0fuWAmgeNjeQIwo5wLnGZFU2gHMH +zZ8inQ+RTtIJfMRNwlr8BJVHKOf20dVEZsPGypxt/H+Sg2I68hoxojDPlrRClLn K5G4PCwnPBGj/f4UM4oiWBV+qbp26WlSed1CgeS1CJZ2wZM+uDhnYBy29JI3PGz1 Mcov9FRKP06GcRTORC3q2uOuLTDWg+KAff9BidDO6oZR/UAwd+brKsfNWHYGlU8T n5r9LCkyF0Sk5aGcYizYMO7Nmh+LrDhm7SKbsI6vI8cZUbabuNp3tN4BEmtceh7h yzqj1Oe+MTmsNOwNSwApckkLAHrvMtDCB0dKEbjtwbFXvMftgd8RPESlxD1TJu2F H1gSWu+aVJx8J5GeFc9kLF4S8Nz6RdwbmYluqMWBaN8tGi75pEdjipI+f3Y6Iu/U /sm0vwOxTne0TkBbfhjK =PPb6 -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 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data
On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote: > ELM address information is provided by device tree. No longer need > to include this information within hwmod. > > Signed-off-by: Franklin S Cooper Jr The OMAP4 DTS files don't have the ELM address space declared. I'm going to drop that portion of your patch. Could you please send a two-patch series that first adds the ELM address space to the OMAP4 DTS file and then subsequently drops it from the OMAP4 hwmod data 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 2/2 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data
On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote: > GPMC address information is provided by device tree. No longer need > to include this information within hwmod. > > Signed-off-by: Franklin S Cooper Jr Thanks, queued. - 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.3-rc6
Here are some basic OMAP test results for Linux v4.3-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc6/20151018200945/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 4/11): 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc5 (25cb62b76430a91cc6195f902e61c2cb84ade622)): text data bsstotal kernel +7200 +72 omap1_defconfig +8000 +80 omap1_defconfig_1510innovator_only +8000 +80 omap1_defconfig_5912osk_only +400 +4 multi_v7_defconfig +12400 +124 omap2plus_defconfig +9200 +92 omap2plus_defconfig_2430sdp_only +12400 +124 omap2plus_defconfig_am33xx_only +6000 +60 omap2plus_defconfig_am43xx_only +6000 +60 omap2plus_defconfig_cpupm +6000 +60 omap2plus_defconfig_dra7xx_only +6000 +60 omap2plus_defconfig_n800_multi_omap2xxx +3200 +32 omap2plus_defconfig_n800_only_a +6000 +60 omap2plus_defconfig_no_pm +60 -80 +52 omap2plus_defconfig_omap2_4_only +124
Re: [PATCH 2/2] ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs
On Mon, 14 Sep 2015, Suman Anna wrote: > Remove the mailbox attribute data, irq info and hwmod addr space > data that are used for creating the legacy-style mailbox devices, > there is no need for these as the support for legacy-mode for this > IP is being dropped. > > Signed-off-by: Suman Anna Thanks, queued. - 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: OMAP4: hwmod data: Remove spinlock hwmod addrs
On Mon, 14 Sep 2015, Suman Anna wrote: > The legacy-style device creation logic for hwspinlock > has been removed after the DT-support was added to the > driver. The hwmod addr space for spinlock is therefore > no longer needed, so remove it. > > Signed-off-by: Suman Anna Thanks, queued. - 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 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data
On Fri, 16 Oct 2015, Roger Quadros wrote: > On 15/10/15 19:27, Franklin S Cooper Jr wrote: > > ELM address information is provided by device tree. No longer need > > to include this information within hwmod. > > > > Signed-off-by: Franklin S Cooper Jr > > Acked-by: Roger Quadros Thanks, queued. - 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 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data
On Fri, 16 Oct 2015, Roger Quadros wrote: > On 15/10/15 19:27, Franklin S Cooper Jr wrote: > > GPMC address information is provided by device tree. No longer need > > to include this information within hwmod. > > > > Signed-off-by: Franklin S Cooper Jr > > Acked-by: Roger Quadros Thanks, queued. - 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: DRA7: hwmod: Remove elm address space from hwmod data
On Wed, 14 Oct 2015, Franklin S Cooper Jr. wrote: > > > On 10/14/2015 01:58 AM, Roger Quadros wrote: > > On 13/10/15 16:44, Franklin S Cooper Jr wrote: > >> ELM address information is provided by device tree. No longer need > >> to include this information within hwmod. > >> > >> Signed-off-by: Franklin S Cooper Jr > > Acked-by: Roger Quadros > > > > Franklin, > > > > Can you please do the same for gpmc_addr as well? > > > > And looks like elm_addr needs to be removed from > > omap_hwmod_33xx_43xx_interconnect_data.c and omap_hwmod_44xx_data.c as > > well, no? > Sure I'll combine the 335x and 44x elm removal with this patch and then > create a separate patch for the gpmc version. OK, holding off on this until you update the patch. - 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.3-rc5
Here are some basic OMAP test results for Linux v4.3-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc5/20151011160547/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc4 (049e6dde7e57f0054fdc49102e7ef4830c698b46)): text data bsstotal kernel +12300 +123 omap1_defconfig +12300 +123 omap1_defconfig_1510innovator_only +12300 +123 omap1_defconfig_5912osk_only -4557-14720-6029 multi_v7_defconfig -8840-22480 -11088 omap2plus_defconfig +19500 +195 omap2plus_defconfig_2430sdp_only -8656-2248 -64 -10968 omap2plus_defconfig_am33xx_only -8664-2312 -64 -11040 omap2plus_defconfig_am43xx_only -8776-22480 -11024 omap2plus_defconfig_cpupm -8840-2248 -64 -11152 omap2plus_defconfig_dra7xx_only -100 -1 omap2plus_defconfig_n800_multi_omap2xxx -4900 -49 omap2plus_defconfig_n800_only_a -8776-23120 -11088 omap2plus_defconfig_no_pm -8600-22400 -10840 omap2plus_defconfig_omap2_4_only -8728-2
OMAP baseline test results for v4.3-rc4
Here are some basic OMAP test results for Linux v4.3-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc4/20151004132242/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc3 (9ffecb10283508260936b96022d4ee43a7798b4c)): text data bsstotal kernel +731 +320 +763 omap1_defconfig +731 +320 +763 omap1_defconfig_1510innovator_only +731 +320 +763 omap1_defconfig_5912osk_only +130500+1305 multi_v7_defconfig +6563 +328 -64+6827 omap2plus_defconfig +6275 +3600+6635 omap2plus_defconfig_2430sdp_only +6559 +3840+6943 omap2plus_defconfig_am33xx_only +6559 +3200+6879 omap2plus_defconfig_am43xx_only +6563 +320 -64+6819 omap2plus_defconfig_cpupm +6559 +328 -64+6823 omap2plus_defconfig_dra7xx_only +6227 +3280+6555 omap2plus_defconfig_n800_multi_omap2xxx +6475 +320 +32+6827 omap2plus_defconfig_n800_only_a +6559 +3200+6879 omap2plus_defconfig_no_pm +6559 +320 -64+6815 omap2plus_defconfi
Re: [PATCH 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3
Hello Péter, On Wed, 30 Sep 2015, Peter Ujfalusi wrote: > On 09/27/2015 10:02 AM, Paul Walmsley wrote: > >> /* > >> + * 'mcasp' class > >> + * > >> + */ > >> +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = { > >> + .sysc_offs = 0x0004, > >> + .sysc_flags = SYSC_HAS_SIDLEMODE, > >> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), > >> + .sysc_fields= &omap_hwmod_sysc_type3, > >> +}; > >> + > >> +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = { > >> + .name = "mcasp", > >> + .sysc = &dra7xx_mcasp_sysc, > >> +}; > >> + > >> +/* mcasp3 */ > >> +static struct omap_hwmod dra7xx_mcasp3_hwmod = { > >> + .name = "mcasp3", > >> + .class = &dra7xx_mcasp_hwmod_class, > >> + .clkdm_name = "l4per2_clkdm", > >> + .main_clk = "mcasp3_ahclkx_mux", > > > > I'd expect this clock to be something derived from mcasp3_aux_gfclk, > > according to Table 24-408 "Clocks and Resets" of SPRUHZ6. Could you > > please doublecheck this? > > I can not explain this. If I change the main_clk to "mcasp3_aux_gfclk_mux" > then I can not access to McASP3 register at all. > I don't see anything popping out in the clock data, nor in other places. OK thank you for testing that. Maybe just add a brief comment along those lines in the hwmod data, above the structure record declaration? > >> + .flags = HWMOD_SWSUP_SIDLE, > > Not sure why this has been added, I can not find any pointers regarding to > this and everything is working w/o this flag. Will remove it in v2. OK thanks. > >> @@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if > >> dra7xx_l3_main_1__hdmi = { > >>.user = OCP_USER_MPU | OCP_USER_SDMA, > >> }; > >> > >> +/* l4_per2 -> mcasp3 */ > >> +static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = { > >> + .master = &dra7xx_l4_per2_hwmod, > >> + .slave = &dra7xx_mcasp3_hwmod, > > > > So this is the low-speed control/register access port, where the MPU > > writes to the McASP3 config registers... > > > >> + .clk= "l3_iclk_div", > > > > ... and thus this interface clock doesn't look right for this port, since > > it's most likely generated from the L4PER2, where this port is connected. > > So it should probably be "l4_iclk_div". > > There is no "l4_iclk_div" for dra7xx. Looking around the file all other script > generated data uses "l3_iclk_div" for IPs under dra7xx_l4_per2_hwmod. > > Tero: do you know the reason for this? Sounds like from your followup E-mail that the clock name to use in the kernel is "l4_root_clk_div", which sounds fine to me. (Haven't looked closely at the clock data, though.) > >> + .user = OCP_USER_MPU | OCP_USER_SDMA, > >> +}; > > > > There's another struct omap_hwmod_ocp_if record missing: the high-speed > > bus-master port that the McASP3 uses to DMA audio data. This port should > > most likely be clocked with "l3_iclk_div" per Table 24-408 "Clocks and > > Resets". This port is also where the registers described in Table 24-555 > > "MCASP_DAT Register Summary 3" L3_MAIN column are exposed. You've got > > that address map range blocked out in your DT data reg property, and > > associated with this device, right? 0x4600? > > Yes, the McASP3-dat port is not used ATM. This is over the L3 interconnect and > due to a feature we can not use it with sDMA (constant addressing is not > supported through L3 interconnect for DMAs). > We could use eDMA, but there are complications regarding to that. > At the moment we are using the sDMA through the L4 interconnect address space. OK thanks for the explanation. The hwmod code prevents links from being registered if no initiator 'users' are listed, so sounds like we should leave it out for now. Could you add a brief comment, similar to your paragraph above, in the data, in case others wonder about the L3 link? After those changes are made, feel free to add my ack. Köszönöm, - Paul
Re: [PATCH v3 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks
On Thu, 24 Sep 2015, Lokesh Vutla wrote: > On Thursday 27 August 2015 09:51 AM, Lokesh Vutla wrote: > > On Thursday 23 July 2015 06:55 PM, Lokesh Vutla wrote: > >> This series implements lock and unlock functions for RTC and hooks > >> the same to DRA7 and AMx3xx hwmod. > >> This is dependent on the patch https://patchwork.kernel.org/patch/6578281/, > >> which is queued recently by Paul. > > Gentle ping on this series. > Do you have any comments on this series? Looks pretty good. I'm slightly concerned about the latency jitter impact on -rt kernels for that local_irq_disable() section. Looks like it could hold off interrupts for ~(50 udelay µs) + 50*((RTC register read time) + 1). But I'm not sure if preempt_enable/disable() is a good alternative since a bunch of interrupt top halves could conceivably run after the RTC goes non-busy and result in the RTC not being locked/unlocked. Is there an RTC IP block register that the code can read, or a safe sequence that the code can execute, after the RTC lock/unlock operation to verify that the RTC has successfully been locked or unlocked? If so then it's probably worth converting the local_irq_disable/enable() to preempt_disable/enable() and testing that, then retrying the lock/unlock if it fails. - Paul
OMAP baseline test results for v4.3-rc3
Here are some basic OMAP test results for Linux v4.3-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc3/20150927222545/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc2 (1f93e4a96c9109378204c147b3eec0d0e8100fde)): text data bsstotal kernel +134600+1346 omap1_defconfig +237000+2370 omap1_defconfig_1510innovator_only +134600+1346 omap1_defconfig_5912osk_only +2246 +256 -64+2438 multi_v7_defconfig +6742 +64 -128+6678 omap2plus_defconfig +2014 +96 -96+2014 omap2plus_defconfig_2430sdp_only +6710 +64 -128+6646 omap2plus_defconfig_am33xx_only +2614 +64 -128+2550 omap2plus_defconfig_am43xx_only +6742 +64 -128+6678 omap2plus_defconfig_cpupm +7498 +64 -128+7434 omap2plus_defconfig_dra7xx_only +5100 +64 -96+5068 omap2plus_defconfig_n800_multi_omap2xxx +458800+4588 omap2plus_defconfig_n800_only_a +6742 +64 -128+6678 omap2plus_defconfig_no_pm +2614 +64 -128+2550 omap2plus_defconfi
Re: [PATCH 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3
Hi Péter, a few comments: On Tue, 15 Sep 2015, Peter Ujfalusi wrote: > McASP3 is used by default on DRA7x based boards for audio. > > Signed-off-by: Peter Ujfalusi > --- > Hi Paul, > > this patch is part of my earlier series and as Tony suggested I'll resend the > hwmod patch for you to review since I missed you from the TO in the series. > > The original series: > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg119319.html > > Regards, > Peter > > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 > +++ > 1 file changed, 41 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > index 562247bced49..c38b7fa30c27 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > @@ -1298,6 +1298,38 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = { > }; > > /* > + * 'mcasp' class > + * > + */ > +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = { > + .sysc_offs = 0x0004, > + .sysc_flags = SYSC_HAS_SIDLEMODE, > + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), > + .sysc_fields= &omap_hwmod_sysc_type3, > +}; > + > +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = { > + .name = "mcasp", > + .sysc = &dra7xx_mcasp_sysc, > +}; > + > +/* mcasp3 */ > +static struct omap_hwmod dra7xx_mcasp3_hwmod = { > + .name = "mcasp3", > + .class = &dra7xx_mcasp_hwmod_class, > + .clkdm_name = "l4per2_clkdm", > + .main_clk = "mcasp3_ahclkx_mux", I'd expect this clock to be something derived from mcasp3_aux_gfclk, according to Table 24-408 "Clocks and Resets" of SPRUHZ6. Could you please doublecheck this? > + .flags = HWMOD_SWSUP_SIDLE, Is this needed? If it is, please add a brief comment describing the issue or bug that it's working around. > + .prcm = { > + .omap4 = { > + .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET, > + .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET, > + .modulemode = MODULEMODE_SWCTRL, > + }, > + }, > +}; > + > +/* > * 'mmc' class > * > */ > @@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi > = { > .user = OCP_USER_MPU | OCP_USER_SDMA, > }; > > +/* l4_per2 -> mcasp3 */ > +static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = { > + .master = &dra7xx_l4_per2_hwmod, > + .slave = &dra7xx_mcasp3_hwmod, So this is the low-speed control/register access port, where the MPU writes to the McASP3 config registers... > + .clk= "l3_iclk_div", ... and thus this interface clock doesn't look right for this port, since it's most likely generated from the L4PER2, where this port is connected. So it should probably be "l4_iclk_div". > + .user = OCP_USER_MPU | OCP_USER_SDMA, > +}; There's another struct omap_hwmod_ocp_if record missing: the high-speed bus-master port that the McASP3 uses to DMA audio data. This port should most likely be clocked with "l3_iclk_div" per Table 24-408 "Clocks and Resets". This port is also where the registers described in Table 24-555 "MCASP_DAT Register Summary 3" L3_MAIN column are exposed. You've got that address map range blocked out in your DT data reg property, and associated with this device, right? 0x4600? > + > static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = { > { > .pa_start = 0x48078000, > @@ -3338,6 +3378,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] > __initdata = { > &dra7xx_l4_wkup__dcan1, > &dra7xx_l4_per2__dcan2, > &dra7xx_l4_per2__cpgmac0, > + &dra7xx_l4_per2__mcasp3, > &dra7xx_gmac__mdio, > &dra7xx_l4_cfg__dma_system, > &dra7xx_l3_main_1__dss, > -- > 2.5.0 > - Paul
OMAP baseline test results for v4.3-rc2
Here are some basic OMAP test results for Linux v4.3-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc2/20150920195237/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 5/17): 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass ( 9/17): am335xbonelt, am335xbone, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 2420n800 Kernel warnings during boot to userspace: FAIL ( 4/17): 4430es2panda, 4460pandaes, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 4/11): 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 3/17): 4430es2panda, 4460pandaes, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc1 (6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f)): text data bsstotal kernel +339800+3398 omap1_defconfig +342200+3422 omap1_defconfig_1510innovator_only +340600+3406 omap1_defconfig_5912osk_only +3110 -720+3038 multi_v7_defconfig -323800-3238 omap2plus_defconfig -54200 -542 omap2plus_defconfig_2430sdp_only -333400-3334 omap2plus_defconfig_am33xx_only -324600-3246 omap2plus_defconfig_am43xx_only -733400-7334 omap2plus_defconfig_cpupm -734200-7342 omap2plus_defconfig_dra7xx_only +87400 +874 omap2plus_defconfig_n800_multi_omap2xxx +104600+1046 omap2plus_defconfig_n800_only_a -723400-7234 omap2plus_defconfig_no_pm -324200
Re: [PATCH] ARM: OMAP: Remove duplicated operand in OR operation
On Mon, 21 Sep 2015, Roger Quadros wrote: > On 17/09/15 16:22, Javier Martinez Canillas wrote: > > Commit b483a4a5a711 ("ARM: OMAP4+: hwmod data: Don't prevent RESET of > > USB Host module") added the SYSC_HAS_RESET_STATUS flag to both OMAP4 > > and OMAP5 USB host module hwmon sysconfig but that flag was already > > set for OMAP5. So now the flag appears twice in the expression. > > > > make coccicheck complains with the following message: > > > > omap_hwmod_54xx_data.c:1846:37-58: duplicated argument to & or | > > > > Signed-off-by: Javier Martinez Canillas > > Acked-by: Roger Quadros Thanks, queued for v4.4. - 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.3-rc1
Here are some basic OMAP test results for Linux v4.3-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc1/20150913170656/ 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-stk-om44, 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 (13/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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_allnoconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 5/17): 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass ( 9/17): am335xbonelt, am335xbone, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 2420n800 Kernel warnings during boot to userspace: FAIL ( 4/17): 4430es2panda, 4460pandaes, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 4/11): 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 3/17): 4430es2panda, 4460pandaes, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2 (64291f7db5bd8150a74ad2036f1037e6a0428df2)): text data bsstotal kernel +289901 +18816+2496 +311213 omap1_defconfig +288849 +18792+2496 +310137 omap1_defconfig_1510innovator_only +284789 +18784+2496 +306069 omap1_defconfig_5912osk_only +490573+6536 +14016 +511125 multi_v7_defconfig +301942 +25296 +39016 +366254 omap2plus_defconfig +261223 +19984 +38824 +320031 omap2plus_defconfig_2430sdp_only +296672 +25592 +39016 +361280 omap2plus_defconfig_am33xx_only +297648 +25976 +38952 +362576 omap2plus_defconfig_am43xx_only +306038 +25304 +39016 +370358 omap2plus_defconfig_cpupm +302160 +25656 +39080 +366896 omap2plus_defconfig_dra7xx_only +287741 +1802
OMAP baseline test results for v4.2
Here are some basic OMAP test results for Linux v4.2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2/20150913144826/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc8 (c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b)): text data bsstotal kernel -16800 -168 omap1_defconfig -16800 -168 omap1_defconfig_1510innovator_only -16800 -168 omap1_defconfig_5912osk_only -4000 -40 multi_v7_defconfig -10800 -108 omap2plus_defconfig -16000 -160 omap2plus_defconfig_2430sdp_only -17200 -172 omap2plus_defconfig_am33xx_only -10800 -108 omap2plus_defconfig_am43xx_only -172 -80 -180 omap2plus_defconfig_cpupm -17200 -172 omap2plus_defconfig_dra7xx_only 0000 omap2plus_defconfig_n800_multi_omap2xxx -3200 -32 omap2plus_defconfig_n800_only_a -17200 -172 omap2plus_defconfig_no_pm -17200 -172 omap2plus_defconfig_omap2_4_only -10800 -108 omap2p
OMAP baseline test results for v4.2-rc8
Here are some basic OMAP test results for Linux v4.2-rc8. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc8/20150825101923/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc7 (2c6625cd545bdd66acff14f3394865d43920a5c7)): text data bsstotal kernel -1269400 -12694 omap1_defconfig -1679000 -16790 omap1_defconfig_1510innovator_only -12726 -320 -12758 omap1_defconfig_5912osk_only -125500-1255 multi_v7_defconfig -1371 -640-1435 omap2plus_defconfig -1443 -320-1475 omap2plus_defconfig_2430sdp_only -1459 -640-1523 omap2plus_defconfig_am33xx_only -1435 -640-1499 omap2plus_defconfig_am43xx_only -1371 -640-1435 omap2plus_defconfig_cpupm -1371 -640-1435 omap2plus_defconfig_dra7xx_only -104700-1047 omap2plus_defconfig_n800_multi_omap2xxx -9500 -95 omap2plus_defconfig_n800_only_a -1371 -640-1435 omap2plus_defconfig_no_pm -1371 -640-1435 omap2plus_defconfig_omap2_4_only -1375 -640-1439
OMAP baseline test results for v4.2-rc7
Here are some basic OMAP test results for Linux v4.2-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc7/20150816230147/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc6 (f7644cbfcdf03528f0f450f3940c4985b2291f49)): text data bsstotal kernel +45600 +456 omap1_defconfig +45600 +456 omap1_defconfig_1510innovator_only +48800 +488 omap1_defconfig_5912osk_only +52800 +528 multi_v7_defconfig +59200 +592 omap2plus_defconfig +55200 +552 omap2plus_defconfig_2430sdp_only +60400 +604 omap2plus_defconfig_am33xx_only +66800 +668 omap2plus_defconfig_am43xx_only +59200 +592 omap2plus_defconfig_cpupm +60400 +604 omap2plus_defconfig_dra7xx_only +40400 +404 omap2plus_defconfig_n800_multi_omap2xxx +41200 +412 omap2plus_defconfig_n800_only_a +59200 +592 omap2plus_defconfig_no_pm +59200 +592 omap2plus_defconfig_omap2_4_only +54000 +540
Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Hi On Thu, 16 Jul 2015, R, Vignesh wrote: > On 07/16/2015 03:24 AM, Paul Walmsley wrote: > > > > On Wed, 3 Jun 2015, Vignesh R wrote: > > > >> Add hwmod entries for the PWMSS on DRA7. > >> > >> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock > >> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2). > >> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4, > >> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually > >> L4PER2_L3_GICLK/2. The TRM does not show the division by 2. > > > > Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]? Or is > > HSPCLKDIV a separate divider after the divide-by-2 you mention above? > > No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK > as clock input for PWMSS. But actually L4PER2_L4_GICLK(=L3_GICLK/2) is > the clock input for PWMSS. This will be updated in TRM soon. OK > >> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > >> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > >> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = { > >>}, > >> }; > >> > >> +/* pwmss */ > >> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = { > >> + .rev_offs = 0x0, > >> + .sysc_offs = 0x4, > >> + .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS, > > > > This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG". There's no > > RESETSTATUS bit. There is a SOFTRESET bit. > > > > Could you please confirm whether this is intentional? > > sorry my bad... I will change this in v3. OK > >> +/* ecap0 */ > >> +struct omap_hwmod dra7xx_ecap0_hwmod = { > >> + .name = "ecap0", > >> + .class = &dra7xx_ecap_hwmod_class, > >> + .clkdm_name = "l4per2_clkdm", > >> + .main_clk = "l4_root_clk_div", > > > > Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", > > there appears to be a local "mini-PRCM" for the PWMSS which implements > > clock gating and reports back on the status of what I'd guess is the local > > clock gating FSM. > > > > So from that point of view, you should probably create a clock driver that > > manages both the clock gate request bit and the FSM status bit. It should > > be something that can be reused for the other PWMSS IP blocks. Then > > you'd create per-IP block clock nodes and set the main_clk to point to > > that node. > > Since, this register is within the config space of PWMSS, the individual > gating and reporting for the modules within PWMSS > (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost > the sole function this driver is doing). It has been the same since > am335x. Adding new clock nodes will result in driver changes and also > changes to am335x, am437x (and other platforms) hwmod files. It also > involves adding new nodes to clocks.dtsi and it will be difficult to > maintain backward compatibility for older platforms. Is it not better to > keep this as is, in order to maintain consistency (with am335x, am437x > etc) and also that these clock bits are within IP's config space? It's certainly possible that we as maintainers didn't look closely enough at the AM33xx data for the PWMSS when we merged it. But if that's incorrect too, then now is the time to fix this. Otherwise it will never get fixed, since each new group of people patching this code will keep punting it off to the indeterminate future. In terms of hwmod data: based on the register maps in sections 29.4.3, 29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices. They don't support the Highlander OCP registers, they have no individual PRCM registers or register bitfields, and all of the idle and status reporting is to the PWMSS top-level IP block itself. So it looks to me like the eCAP, eQEP, and ePWM modules should be registered via DT, rather than via hwmod. It looks like you can get away with using the "simple-bus" abstraction, but you might ultimately have to define something custom here. However, the PWMSS top level subsystem, described in section 29.1, does have the OCP registers, sideband signals, etc., and thus should remain a hwmod-registered device (via DT). In terms of the clock data: based on section 29.1.4, section 29.1.5.2, figure 29-3, and table 29-4, there are several clock gating control bits. These should be modeled as clock nodes in the Linux common clock framework. Furthermore these register
Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support
Hi guys On Wed, 12 Aug 2015, Alexandre Belloni wrote: > On 13/08/2015 at 00:38:50 +0530, Keerthy wrote : > > The intent here is to switch to a higher precision clock which is the > > internal clock when available. > > > > Alexandre, > > > > Is dynamic switching preferred over sticking to external clock always if > > present? > > I'd say that I don't really care. I'd say the best would be to make a > decision based on clock-accuracy but maybe that is an information you > don't have yet. Anyway, this could be added at a later date. Either the clock mux logic is glitchless, in which case the RTC is likely to lose at least 31 microseconds per switch; or it's not glitchless, in which case it's unsafe to switch the RTC clock source while the clock isn't gated. Keerthy, before submitting this patch for merging, I'd suggest consulting your hardware folks to figure out which case it is. - 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 5/6] ARM: AM43XX: HWMOD: Add rtc hwmod
On Mon, 10 Aug 2015, Keerthy wrote: > The patch adds rtc hwmod. This is present on gp and sk evm and not on > epos evm. Hence adding it selectively using a seprate list. > > Signed-off-by: Keerthy So just to confirm, the RTC IP block has been physically removed or permanently disabled on these new AM438x chips? So the registers are no longer accessible by the MPU? Is there a TRM available for these chips? - 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 2/6] rtc: omap: Add external clock enabling support
On Mon, 10 Aug 2015, Keerthy wrote: > Switch to external clock source during suspend and switch back > to internal source on resume. This helps rtc ticking across suspend. Doesn't this type of dynamic switching make it likely that ticks will be lost? If the external, optional source is present, isn't it best just to use the external source 100% of the 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
OMAP baseline test results for v4.2-rc6
Here are some basic OMAP test results for Linux v4.2-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc6/20150810114017/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc5 (74d33293e467df61de1b1d8b2fbe29e550dec33b)): text data bsstotal kernel +25100 +251 omap1_defconfig +25100 +251 omap1_defconfig_1510innovator_only +25100 +251 omap1_defconfig_5912osk_only +54000 +540 multi_v7_defconfig +444300+4443 omap2plus_defconfig +12700 +127 omap2plus_defconfig_2430sdp_only +34700 +347 omap2plus_defconfig_am33xx_only +34700 +347 omap2plus_defconfig_am43xx_only +34700 +347 omap2plus_defconfig_cpupm +34700 +347 omap2plus_defconfig_dra7xx_only +41500 +415 omap2plus_defconfig_n800_multi_omap2xxx +43500 +435 omap2plus_defconfig_n800_only_a +34700 +347 omap2plus_defconfig_no_pm +34700 +347 omap2plus_defconfig_omap2_4_only +41500 +415
OMAP baseline test results for v4.2-rc5
Here are some basic OMAP test results for Linux v4.2-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc5/20150809200304/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc5 (74d33293e467df61de1b1d8b2fbe29e550dec33b)): 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 0000 omap2plus_defconfig_am33xx_only 0000 omap2plus_defconfig_am43xx_only 0000 omap2plus_defconfig_cpupm 0000 omap2plus_defconfig_dra7xx_only 0000 omap2plus_defconfig_n800_multi_omap2xxx 0000 omap2plus_defconfig_n800_only_a 0000 omap2plus_defconfig_no_pm 0000 omap2plus_defconfig_omap2_4_only 0000
OMAP baseline test results for v4.2-rc4
Here are some basic OMAP test results for Linux v4.2-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc4/20150730100856/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc3 (52721d9d3334c1cb1f76219a161084094ec634dc)): text data bsstotal kernel +819 +640 +883 omap1_defconfig +819 +960 +915 omap1_defconfig_1510innovator_only +851 +640 +915 omap1_defconfig_5912osk_only +99 +1280 +227 multi_v7_defconfig +35600 +356 omap2plus_defconfig +79200 +792 omap2plus_defconfig_2430sdp_only +35600 +356 omap2plus_defconfig_am33xx_only +445200+4452 omap2plus_defconfig_am43xx_only +35600 +356 omap2plus_defconfig_cpupm +35600 +356 omap2plus_defconfig_dra7xx_only -470 -32 -79 omap2plus_defconfig_n800_multi_omap2xxx -22800 -228 omap2plus_defconfig_n800_only_a +54000 +540 omap2plus_defconfig_no_pm +35600 +356 omap2plus_defconfig_omap2_4_only +35600 +356
OMAP baseline test results for v4.2-rc3
Here are some basic OMAP test results for Linux v4.2-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc3/20150728081114/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc2 (bc0195aad0daa2ad5b0d76cce22b167bc3435590)): text data bsstotal kernel +609 +2240 +833 omap1_defconfig +609 +1920 +801 omap1_defconfig_1510innovator_only +609 +2240 +833 omap1_defconfig_5912osk_only +70200 +702 multi_v7_defconfig +150 +1280 +278 omap2plus_defconfig +241 +960 +337 omap2plus_defconfig_2430sdp_only +150 +1280 +278 omap2plus_defconfig_am33xx_only +382 +1280 +510 omap2plus_defconfig_am43xx_only +150 +1280 +278 omap2plus_defconfig_cpupm +146 +1280 +274 omap2plus_defconfig_dra7xx_only +213 +960 +309 omap2plus_defconfig_n800_multi_omap2xxx +4100 +41 omap2plus_defconfig_n800_only_a +182 +1280 +310 omap2plus_defconfig_no_pm +146 +1280 +274 omap2plus_defconfig_omap2_4_only +146 +1280 +274
Re: [PATCH v3] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc
On Mon, 27 Jul 2015, Roger Quadros wrote: > Hi, > > On 16/07/15 16:16, Roger Quadros wrote: > > For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so > > _find_mpu_rt_port(oh) will return NULL thus preventing ready state check > > on those modules after the module is enabled. > > > > This can potentially cause a bus access error if the module is accessed > > before the module is ready. > > > > Fix this by unconditionally calling _init_mpu_rt_base() during hwmod > > _init(). Do ioremap only if we need SYSC access. > > > > Eventhough _wait_target_ready() check doesn't really need MPU RT port but > > just the PRCM registers, we still mandate that the hwmod must have an > > MPU RT port if ready state check needs to be done. Else it would mean that > > the module is not accessible by MPU so there is no point in waiting > > for target to be ready. > > > > e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. > > > > [ 16.672978] [ cut here ] > > [ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 > > l3_interrupt_handler+0x234/0x35c() > > [ 16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET > > L4_PER_0 (Read): Data Access in User mode during Functional access > > [ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 > > videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc > > kfifo_buf industrialio c_can_platform videobuf2_dma_contig media > > snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc > > [ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted > > 3.14.26-02561-gf733aa036398 #180 > > [ 16.739747] Backtrace: > > [ 16.742336] [] (dump_backtrace) from [] > > (show_stack+0x18/0x1c) > > [ 16.750285] r6:0093 r5:0009 r4:eab5b8a8 r3: > > [ 16.756252] [] (show_stack) from [] > > (dump_stack+0x20/0x28) > > [ 16.763870] [] (dump_stack) from [] > > (warn_slowpath_common+0x6c/0x8c) > > [ 16.772408] [] (warn_slowpath_common) from [] > > (warn_slowpath_fmt+0x38/0x40) > > [ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210 > > [ 16.788626] [] (warn_slowpath_fmt) from [] > > (l3_interrupt_handler+0x234/0x35c) > > [ 16.797968] r3:ed0cd480 r2:c0730508 > > [ 16.801747] [] (l3_interrupt_handler) from [] > > (handle_irq_event_percpu+0x54/0x1bc) > > [ 16.811533] r10:ed005600 r9:c084855b r8:002a r7: > > r6: r5:002a > > [ 16.819780] r4:ed0e6d80 > > [ 16.822453] [] (handle_irq_event_percpu) from [] > > (handle_irq_event+0x30/0x40) > > [ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 > > r6: r5:002a > > [ 16.840052] r4:ed005600 > > [ 16.842744] [] (handle_irq_event) from [] > > (handle_fasteoi_irq+0x74/0x128) > > [ 16.851702] r4:ed005600 r3: > > [ 16.855479] [] (handle_fasteoi_irq) from [] > > (generic_handle_irq+0x28/0x38) > > [ 16.864523] r4:002a r3:c0066164 > > [ 16.868294] [] (generic_handle_irq) from [] > > (handle_IRQ+0x38/0x8c) > > [ 16.876612] r4:c081c640 r3:0202 > > [ 16.880380] [] (handle_IRQ) from [] > > (gic_handle_irq+0x30/0x5c) > > [ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100 > > [ 16.894303] [] (gic_handle_irq) from [] > > (__irq_svc+0x40/0x50) > > [ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80) > > [ 16.907499] ba20: > > 0006 > > [ 16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 > > bf011420 eb2b6960 > > [ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c > > 600f0013 > > [ 16.933317] r7:eab5ba6c r6: r5:600f0013 r4:bf07702c > > [ 16.939317] [] (c_can_plat_read_reg_aligned_to_16bit > > [c_can_platform]) from [] (c_can_get_berr_counter+0x38/0x64 > > [c_can]) > > [ 16.952696] [] (c_can_get_berr_counter [c_can]) from > > [] (can_fill_info+0x124/0x15c [can_dev]) > > [ 16.963480] r5:ec8c9740 r4:ed3d3000 > > [ 16.967253] [] (can_fill_info [can_dev]) from [] > > (rtnl_fill_ifinfo+0x58c/0x8fc) > > [ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780 > > [ 16.981613] [] (rtnl_fill_ifinfo) from [] > > (rtnl_dump_ifinfo+0xf0/0x1dc) > > [ 16.990401] r10:ec8c9740 r9: r8: r7: > > r6:ebd4d1b4 r5:ed3d3000 > > [ 16.998671] r4: > > [ 17.001342] [] (rtnl_dump_ifinfo) from [] > > (netlink_dump+0xa8/0x1e0) > > [ 17.009772] r10: r9: r8:c0503318 r7:ebf3e6c0 > > r6:ebd4d1b4 r5:ec8c9740 > > [ 17.018050] r4:ebd4d000 > > [ 17.020714] [] (netlink_dump) from [] > > (__netlink_dump_start+0x104/0x154) > > [ 17.029591] r6:eab5bd34 r5:ec8c9980 r4:ebd4d000 > > [ 17.034454] [] (__netlink_dump_start) from [] > > (rtnetlink_rcv_msg+0x110/0x1f4) > > [ 17.043778] r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0 > > [ 17.049743] [] (rtnetlink_rcv_msg) from [] > > (netlink_rcv_skb+0xb4/0xc8) > > [ 17.
[GIT PULL] ARM: OMAP2+: PRCM and hwmod changes for v4.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.3/omap-hwmod-prcm-a for you to fetch changes up to 3b86616e3058462c340710dc7a5ac34ec8453944: Merge branch 'prcm-a-for-v4.3' into hwmod-prcm-for-v4.3 (2015-07-23 08:49:57 -0600) - ARM: OMAP2+: PRCM and hwmod changes for v4.3 This series adds: - - I/O wakeup support for AM43xx - - register lock and unlock support to the hwmod code (needed for the RTC IP blocks on some chips) - - several fixes for sparse warnings and an unnecessary null pointer test - - a DRA7xx clockdomain configuration workaround, to deal with some hardware bugs Basic build, boot, and PM tests are here: http://www.pwsan.com/omap/testlogs/hwmod-prcm-for-v4.3/20150723080012/ Since I do not have an AM43xx or DRA7xx device, I can't test on those platforms. - Keerthy (6): ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register ARM: AM43xx: Add the PRM IRQ register offsets ARM: dts: AM4372: Add PRCM IRQ entry ARM: OMAP: PRM: Remove hardcoding of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 register offsets ARM: OMAP4+: PRM: Add AM437x specific data ARM: PRM: AM437x: Enable IO wakeup feature Lokesh Vutla (1): ARM: OMAP2+: hwmod: add support for lock and unlock hooks Markus Elfring (1): ARM: OMAP2: Delete an unnecessary check Paul Walmsley (1): Merge branch 'prcm-a-for-v4.3' into hwmod-prcm-for-v4.3 Sekhar Nori (2): ARM: OMAP2+: sparse: add missing static declaration ARM: OMAP2+: sparse: add missing function declarations Vignesh R (1): ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP arch/arm/boot/dts/am4372.dtsi | 1 + arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 2 +- arch/arm/mach-omap2/omap3-restart.c| 1 + arch/arm/mach-omap2/omap4-restart.c| 1 + arch/arm/mach-omap2/omap_hwmod.c | 13 + arch/arm/mach-omap2/omap_hwmod.h | 4 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 +- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 34 ++-- arch/arm/mach-omap2/pdata-quirks.c | 6 +-- arch/arm/mach-omap2/prcm-common.h | 2 + arch/arm/mach-omap2/prcm43xx.h | 7 +++ arch/arm/mach-omap2/prm44xx.c | 61 +- arch/arm/mach-omap2/prm_common.c | 1 + arch/arm/mach-omap2/timer.c| 3 +- 16 files changed, 92 insertions(+), 50 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVsQCiAAoJEMePsQ0LvSpLSxUP/2BIP8+R5r6CGzsSF/r5uQny aEYZoVPnB7bnTQJnrkrIlkj+oGoH+5JwMX4/v1G6/y6p9f5tTon9uvZSzSkJsW/k mmm4LPK+lX4UiCDRw6w21rJD2DrRUlpXqFSsfdK8XwY94dx1eGWB+bZBcoJXQb7/ 67ge693e6/ZCtg4J1BA1SMXnk9vaa4seDJ1N4AY09fJtROno30tUS7gfBanXi1Ht EQ8FIRB68tTwzrUAnG6osyDR1av/hB1nj9OX4VfoAzgPceyc7u33zUpo5iat1+Ib iAQjdvdMYYFpT7ExuXNSmrLT7v0W0bJ950EDy7XHss4Q/F8Fyevo96dRecypM4wx nCo5a5zk378tlVpPILcTYcrAYax1pU6z0FVc7ghTG7/lYMEe2YRD8mdqSwuLMyHZ GG1ofYX8WNEWai0SyPwGECSNFQXxrgbCqLlWzoJk8t4RjE9yHJEr+b1gi7Wh0/ZB KZMb6rSMzP5tmyQOjIhuQxTlFwZV44noJHf55wyIk1OFmiDPkGjKw5HaLttxb5V2 yJOLSJQ0+CpMakDBwWQd8oWTuiDX9VxbUXZxIndEAoEc9YpTmFg2hUwwLqrAI/6/ Y+J3XHkfwxj8va+FRdY6dZsh51Fq+o6yUoweuwsUUOwyrkuaI2p6iZGTHvjiOyt+ w9T0RwVuta9hX19Bc2gF =9zrq -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
[GIT PULL] ARM: OMAP2+: hwmod fixes for v4.2-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.2-rc/omap-fixes-a for you to fetch changes up to 9a258afa928b45e6dd2efcac46ccf7eea705d35a: ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc (2015-07-23 06:35:25 -0600) - ARM: OMAP2+: hwmod fixes for v4.2-rc Two fixes against v4.2-rc1. The first, for DRA7xx platforms, corrects some incorrect GPMC hardware description data. The second one will ensure that the hwmod code will wait for any module with CPU-accessible registers to become ready before attempting to access it. Basic build, boot, and PM test logs are available here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v4.2-rc/20150723065408/ Note that I do not have a DRA7xx or AM43xx board, and therefore cannot test on those platforms. - Roger Quadros (2): ARM: DRA7: hwmod: fix gpmc hwmod ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc arch/arm/mach-omap2/omap_hwmod.c | 24 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 5 ++--- 2 files changed, 18 insertions(+), 11 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVsPKkAAoJEMePsQ0LvSpLcXoP/1WSdYaC65HEPHJjDV3Wpq5L vKmjqXnLiYzcpdjX7ByTa0SiUwMRNie4P0N1Zm0yTjRCoJIrnmAI/GB9ZXq/E7wN RTTZoEaq+Cqt69JY4xySL8ASTgXPMZkelNOH9JO8/yMWHKE3WEDnhDJ32QN/3Isf WF7GDJQC/utlHS4BgFoQBpBv2LSgrqrt+TsX1CKqWhvVTd4moPNBXtNoCb7VC5P3 ciuUWNFi4y+g1zAPyhe/Q1bzRyDRefEFUesyRx3aHGpTd3VLHWvSK9tEqSjt+EM4 LA/l5lRHjAFcTGuSBRytpE1zhPW7+gSWgFLsJYDnfXmo7Sp9IgFr3Dcbcj++Sbj0 HD64ZXQPfn0WRPphZNh8h6+KWVfXv9x8pLmAzy7zn2w7qPBEWMurjbdvUSF2aczZ tU+kf+YAyOwA36Goj+NeBqdno0lHPU7++HeHywx5znNFpExqQ+r/T0pOqAmDxPJS PFUSE67ax+AkIyS9syCaTDYrj3Al5pOvqjWdMgtETKZdfDbK1r5dFdv+ywO1hIKj Y5/n8rBfRZRL33Y6pd/kvEf9y7vMgMMhUDfEX1QJoh0karrvLPJGtBQhRs11n11Q PZ+MOh5I6ZPz3zTlcAyCqKVeebcJN5DQmuntuK3raDDllPGGrgPO2vNsjbqSC9DO +z4jg0SH51c0LgK/Eum5 =UnJq -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 v4 0/4] AM437x: Add IO wake up support
On Thu, 16 Jul 2015, Keerthy wrote: > The patch series adds IO wake up support for AM437x series > making use of the existing OMAP4 support. Adds the AM437x > specifics. > > Note: Previous series patch 2 and 4 of the previous series are already > queued for v4.3 by Paul. Fixed the comments on the remaining patches > and posting them. > > Changes in v4: > > Added more details to commit logs and kernel documentation for the added > field in a structure. > > Changes in v3: > > Fixed a bug. Assigned nr_regs = 1 for am437x > > Changes in v2: > > Removed inefficient way of using arrays for irq ack and masks. > > Keerthy (4): > ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register > ARM: dts: AM4372: Add PRCM IRQ entry > ARM: OMAP4+: PRM: Add AM437x specific data > ARM: PRM: AM437x: Enable IO wakeup feature > > arch/arm/boot/dts/am4372.dtsi | 1 + > arch/arm/mach-omap2/prcm-common.h | 2 ++ > arch/arm/mach-omap2/prm44xx.c | 23 +-- > arch/arm/mach-omap2/prm_common.c | 1 + > 4 files changed, 21 insertions(+), 6 deletions(-) Thanks, queued these. - 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 1/3] ARM: hwmod: RTC: Add lock and unlock functions
Hi On Fri, 17 Jul 2015, 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 to be > written to KICK registers. > Introduce omap_hwmod_rtc_unlock/lock functions, which writes into these > KICK registers inorder to lock and unlock RTC registers. > > Signed-off-by: Lokesh Vutla Please add kerneldoc for the omap_hwmod_rtc_lock() function. - Paul > --- > arch/arm/mach-omap2/omap_hwmod.h | 2 ++ > arch/arm/mach-omap2/omap_hwmod_reset.c | 56 > ++ > 2 files changed, 58 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod.h > b/arch/arm/mach-omap2/omap_hwmod.h > index c697b57..173a31e 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.h > +++ b/arch/arm/mach-omap2/omap_hwmod.h > @@ -748,6 +748,8 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod > *oh); > */ > > extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh); > +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh); > +void omap_hwmod_rtc_lock(struct omap_hwmod *oh); > > /* > * Chip variant-specific hwmod init routines - XXX should be converted > diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c > b/arch/arm/mach-omap2/omap_hwmod_reset.c > index 65e186c..eebadb2 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_reset.c > +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c > @@ -29,6 +29,16 @@ > #include > > #include "omap_hwmod.h" > +#include "common.h" > + > +#define OMAP_RTC_STATUS_REG 0x44 > +#define OMAP_RTC_KICK0_REG 0x6c > +#define OMAP_RTC_KICK1_REG 0x70 > + > +#define OMAP_RTC_KICK0_VALUE 0x83E70B13 > +#define OMAP_RTC_KICK1_VALUE 0x95A4F1E0 > +#define OMAP_RTC_STATUS_BUSY BIT(0) > +#define OMAP_RTC_MAX_READY_TIME 50 > > /** > * omap_hwmod_aess_preprogram - enable AESS internal autogating > @@ -51,3 +61,49 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh) > > return 0; > } > + > +/** > + * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag > + * @oh: struct omap_hwmod * > + * > + * For updating certain RTC registers, the MPU must wait > + * for the BUSY status in OMAP_RTC_STATUS_REG to become zero. > + * Once the BUSY status is zero, there is a 15-μs access > + * period in which the MPU can program. > + */ > +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh) > +{ > + int i; > + > + /* BUSY may stay active for 1/32768 second (~30 usec) */ > + omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG) > + & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i); > + /* now we have ~15 usec to read/write various registers */ > +} > + > +/** > + * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism. > + * @oh: struct omap_hwmod * > + * > + * RTC IP have kicker feature. This prevents spurious writes to its > registers. > + * In order to write into any of the RTC registers, KICK values has te be > + * written in respective KICK registers. This is needed for hwmod to write > into > + * sysconfig register. > + */ > +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh) > +{ > + local_irq_disable(); > + omap_rtc_wait_not_busy(oh); > + omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG); > + omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG); > + local_irq_enable(); > +} > + > +void omap_hwmod_rtc_lock(struct omap_hwmod *oh) > +{ > + local_irq_disable(); > + omap_rtc_wait_not_busy(oh); > + omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG); > + omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG); > + local_irq_enable(); > +} > -- > 2.1.4 > - Paul
Re: [PATCH] ARM: OMAP2: Delete unnecessary checks before three function calls
On Wed, 15 Jul 2015, Tony Lindgren wrote: > * Paul Walmsley [150715 22:58]: > > Hello Markus > > > > On Tue, 30 Jun 2015, SF Markus Elfring wrote: > > > > > From: Markus Elfring > > > Date: Tue, 30 Jun 2015 14:00:16 +0200 > > > > > > The functions clk_disable(), of_node_put() and omap_device_delete() test > > > whether their argument is NULL and then return immediately. > > > Thus the test around the call is not needed. > > > > > > This issue was detected by using the Coccinelle software. > > > > > > Signed-off-by: Markus Elfring > > > > Thanks for the patch. I have to say, I am a bit leery about applying the > > omap_device.c and omap_hwmod.c changes, since the called functions -- > > omap_device_delete() and clk_disable() -- don't explicitly document that > > NULLs are allowed to be passed in. So there's no explicit contract that > > callers can rely upon, to (at least in theory) prevent those internal NULL > > pointer checks from being removed. > > > > So I would suggest that those two functions' kerneldoc be patched first to > > explicitly state that passing in a NULL pointer is allowed. Then I would > > feel a bit more comfortable applying the omap_device.c and omap_hwmod.c > > changes. > > > > The kerneldoc for of_node_put() does explicitly allow NULLs to be passed > > in. So I'll apply that change now for v4.3, touching up the commit > > message accordingly. > > I have them applied from a later thread already, but will drop both in > my branch as I have not pushed them out yet. Oops sorry about stepping on your toes - I obviously missed that followup. - 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/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks
On Thu, 16 Jul 2015, Tero Kristo wrote: > On 07/16/2015 03:15 AM, Paul Walmsley wrote: > > On Tue, 14 Jul 2015, Tero Kristo wrote: > > > > > On 07/14/2015 01:09 PM, Lokesh Vutla wrote: > > > > Hi, > > > > On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote: > > > > > Some IP blocks like RTC, needs an additional unlocking mechanism for > > > > > writing to its registers. This patch adds optional lock and unlock > > > > > function pointers to the IP block's hwmod data which gets executed > > > > > before and after writing into IP sysconfig register. > > > > > And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod > > > > > data, > > > > > so that sysconfig registers are updated properly. > > > > ping on this series. > > > > > > > > Thanks and regards, > > > > Lokesh > > > > > > > [...] > > > > > It is also racy, as there is no locking in place to avoid concurrent > > > access to > > > the lock/unlock registers across hwmod+driver. > > > > I don't see the race. Where is it? > > See drivers/rtc/rtc-omap.c, am3352_rtc_unlock and am3352_rtc_lock. > > That code is accessing the exact same registers. I guess my question is, when is it possible that code could race with the hwmod code for the same device? - 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/1] add pwm capability to dm816x
Hello Brian, On Mon, 15 Jun 2015, Brian Hutchinson wrote: > Clocks 4-7 are capable of PWM output on dm816x. > > This adds the pwm capability to those timers. > > Cc: Paul Walmsley > Cc: Tero Kristo > Cc: Tony Lindgren > Signed-off-by: Brian Hutchinson > This patch seems to be corrupted. The above line doesn't look right; there are some spurious newlines in the patch header, and tabs seem to have been converted to whitespace. Some of these issues may be due to mailer problems. Could you please fix and try again? - Paul > > --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c_orig 2015-06-15 > 13:20:43.174343431 -0400 > +++ arch/arm/mach-omap2/omap_hwmod_81xx_data.c 2015-06-15 > 13:34:51.770551392 -0400 > @@ -546,6 +546,14 @@ static struct omap_timer_capability_dev_ > .timer_capability = OMAP_TIMER_ALWON, > }; > > +/* pwm timers dev attribute. > + * timers 4-7 may be used for PWM output - see datasheet timer terminal > + * functions table > + */ > +static struct omap_timer_capability_dev_attr capability_pwm_dev_attr = { > + .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_HAS_PWM, > +}; > + > static struct omap_hwmod dm816x_timer1_hwmod = { > .name = "timer1", > .clkdm_name = "alwon_l3s_clkdm", > @@ -619,7 +627,7 @@ static struct omap_hwmod dm816x_timer4_h > .modulemode = MODULEMODE_SWCTRL, > }, > }, > - .dev_attr = &capability_alwon_dev_attr, > + .dev_attr = &capability_pwm_dev_attr, > .class = &dm816x_timer_hwmod_class, > }; > > @@ -640,7 +648,7 @@ static struct omap_hwmod dm816x_timer5_h > .modulemode = MODULEMODE_SWCTRL, > }, > }, > - .dev_attr = &capability_alwon_dev_attr, > + .dev_attr = &capability_pwm_dev_attr, > .class = &dm816x_timer_hwmod_class, > }; > > @@ -661,7 +669,7 @@ static struct omap_hwmod dm816x_timer6_h > .modulemode = MODULEMODE_SWCTRL, > }, > }, > - .dev_attr = &capability_alwon_dev_attr, > + .dev_attr = &capability_pwm_dev_attr, > .class = &dm816x_timer_hwmod_class, > }; > > @@ -682,7 +690,7 @@ static struct omap_hwmod dm816x_timer7_h > .modulemode = MODULEMODE_SWCTRL, > }, > }, > - .dev_attr = &capability_alwon_dev_attr, > + .dev_attr = &capability_pwm_dev_attr, > .class = &dm816x_timer_hwmod_class, > }; > - 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: Delete unnecessary checks before three function calls
Hello Markus On Tue, 30 Jun 2015, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 30 Jun 2015 14:00:16 +0200 > > The functions clk_disable(), of_node_put() and omap_device_delete() test > whether their argument is NULL and then return immediately. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks for the patch. I have to say, I am a bit leery about applying the omap_device.c and omap_hwmod.c changes, since the called functions -- omap_device_delete() and clk_disable() -- don't explicitly document that NULLs are allowed to be passed in. So there's no explicit contract that callers can rely upon, to (at least in theory) prevent those internal NULL pointer checks from being removed. So I would suggest that those two functions' kerneldoc be patched first to explicitly state that passing in a NULL pointer is allowed. Then I would feel a bit more comfortable applying the omap_device.c and omap_hwmod.c changes. The kerneldoc for of_node_put() does explicitly allow NULLs to be passed in. So I'll apply that change now for v4.3, touching up the commit message accordingly. regards, - Paul > --- > arch/arm/mach-omap2/omap_device.c | 3 +-- > arch/arm/mach-omap2/omap_hwmod.c | 5 + > arch/arm/mach-omap2/timer.c | 3 +-- > 3 files changed, 3 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_device.c > b/arch/arm/mach-omap2/omap_device.c > index 4cb8fd9..196366e 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -193,8 +193,7 @@ static int _omap_device_notifier_call(struct > notifier_block *nb, > > switch (event) { > case BUS_NOTIFY_DEL_DEVICE: > - if (pdev->archdata.od) > - omap_device_delete(pdev->archdata.od); > + omap_device_delete(pdev->archdata.od); > break; > case BUS_NOTIFY_ADD_DEVICE: > if (pdev->dev.of_node) > diff --git a/arch/arm/mach-omap2/omap_hwmod.c > b/arch/arm/mach-omap2/omap_hwmod.c > index d78c12e..1091ee7 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.c > +++ b/arch/arm/mach-omap2/omap_hwmod.c > @@ -921,10 +921,7 @@ static int _disable_clocks(struct omap_hwmod *oh) > int i = 0; > > pr_debug("omap_hwmod: %s: disabling clocks\n", oh->name); > - > - if (oh->_clk) > - clk_disable(oh->_clk); > - > + clk_disable(oh->_clk); > p = oh->slave_ports.next; > > while (i < oh->slaves_cnt) { > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c > index cac46d8..15448221 100644 > --- a/arch/arm/mach-omap2/timer.c > +++ b/arch/arm/mach-omap2/timer.c > @@ -208,8 +208,7 @@ static void __init omap_dmtimer_init(void) > /* If we are a secure device, remove any secure timer nodes */ > if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) { > np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure"); > - if (np) > - of_node_put(np); > + of_node_put(np); > } > } > > -- > 2.4.5 > - 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+: sparse: add missing function declarations
On Sat, 11 Jul 2015, Sekhar Nori wrote: > omap3xxx_restart() and omap44xx_restart() are global > functions declared in common.h. Include this file > in omap3-restart.c and omap4-restart.c to prevent > sparse warnings of type: > > arch/arm/mach-omap2/omap4-restart.c:22:6: warning: symbol 'omap44xx_restart' > was not declared. Should it be static? > > Signed-off-by: Sekhar Nori Thanks, queued for v4.3. - 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+: sparse: add missing static declaration
On Sat, 11 Jul 2015, Sekhar Nori wrote: > Add missing static declaration for file local variables. > This fixes sparse warnings of type: > > arch/arm/mach-omap2/omap_hwmod_81xx_data.c:491:26: warning: symbol > 'dm81xx_alwon_l3_slow__gpmc' was not declared. Should it be static? > > Signed-off-by: Sekhar Nori Thanks, queued for v4.3. - 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 6/6] ARM: PRM: AM437x: Enable IO wakeup feature
Hi On Tue, 14 Jul 2015, Keerthy wrote: > Enable IO wakeup feature. > > Signed-off-by: Keerthy Per my comments on one of the previous patches, please add a short description in the commit message for what enabling I/O wakeup will do for a user. - 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 4/6] ARM: OMAP: PRM: Remove hardcoding of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 register offsets
On Wed, 8 Jul 2015, Keerthy wrote: > The register offsets of IRQENABLE_MPU_2 and IRQSTATUS_MPU_2 are hardcoded. > This makes it difficult to reuse the code for SoCs like AM437x that have > a single instance of IRQENABLE_MPU and IRQSTATUS_MPU registers. > Hence handling the case using offset of 4 to accommodate single set of IRQ* > registers generically. > > Signed-off-by: Keerthy Thanks, queued for v4.3. - 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 2/6] ARM: AM43xx: Add the PRM IRQ register offsets
On Thu, 16 Jul 2015, Paul Walmsley wrote: > On Wed, 8 Jul 2015, Keerthy wrote: > > > Add the PRM IRQ register offsets. > > > > Signed-off-by: Keerthy > > Please add more detail to your commit messages so they conform to > Documentation/SubmittingPatches: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 > > For example, this commit message should read something like: > > --- > > ARM: AM43xx: Add the PRM IRQ register offsets > > Add the PRM IRQ register offsets. This is needed to support PRM I/O > wakeup on AM43xx. > > -- > > Basically, your patches need to provide context as to _why_ the change is > needed. > > I've fixed the message for this patch, and queued it for v4.3, but > please take care with this issue in the future. Also I've moved the AM43XX_PRM_IO_PMCTRL_OFFSET macro out of the AM43XX CM section, since it doesn't belong there. - 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 2/6] ARM: AM43xx: Add the PRM IRQ register offsets
On Wed, 8 Jul 2015, Keerthy wrote: > Add the PRM IRQ register offsets. > > Signed-off-by: Keerthy Please add more detail to your commit messages so they conform to Documentation/SubmittingPatches: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n109 For example, this commit message should read something like: --- ARM: AM43xx: Add the PRM IRQ register offsets Add the PRM IRQ register offsets. This is needed to support PRM I/O wakeup on AM43xx. -- Basically, your patches need to provide context as to _why_ the change is needed. I've fixed the message for this patch, and queued it for v4.3, but please take care with this issue in the future. - 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 1/6] ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register
Hi a few minor comments On Wed, 8 Jul 2015, Keerthy wrote: > PRM_IO_PMCTRL_OFFSET need not be same for all SOCs hence > remove hardcoding and use the value provided by the omap_prcm_irq_setup > structure. Please mention here that the reason why you're making this change is to support AM437x. > > Signed-off-by: Keerthy > --- > arch/arm/mach-omap2/prcm-common.h | 1 + > arch/arm/mach-omap2/prm44xx.c | 11 ++- > 2 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/mach-omap2/prcm-common.h > b/arch/arm/mach-omap2/prcm-common.h > index 6ae0b3a..2e60406 100644 > --- a/arch/arm/mach-omap2/prcm-common.h > +++ b/arch/arm/mach-omap2/prcm-common.h > @@ -494,6 +494,7 @@ struct omap_prcm_irq { > struct omap_prcm_irq_setup { > u16 ack; > u16 mask; > + u16 pm_ctrl; Please add a kerneldoc structure documentation line for this new field, to match the existing documentation here. > u8 nr_regs; > u8 nr_irqs; > const struct omap_prcm_irq *irqs; > diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c > index 4541700..8149e5a 100644 > --- a/arch/arm/mach-omap2/prm44xx.c > +++ b/arch/arm/mach-omap2/prm44xx.c > @@ -45,6 +45,7 @@ static const struct omap_prcm_irq omap4_prcm_irqs[] = { > static struct omap_prcm_irq_setup omap4_prcm_irq_setup = { > .ack= OMAP4_PRM_IRQSTATUS_MPU_OFFSET, > .mask = OMAP4_PRM_IRQENABLE_MPU_OFFSET, > + .pm_ctrl= OMAP4_PRM_IO_PMCTRL_OFFSET, > .nr_regs= 2, > .irqs = omap4_prcm_irqs, > .nr_irqs= ARRAY_SIZE(omap4_prcm_irqs), > @@ -306,10 +307,10 @@ static void omap44xx_prm_reconfigure_io_chain(void) > omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, > OMAP4430_WUCLK_CTRL_MASK, > inst, > - OMAP4_PRM_IO_PMCTRL_OFFSET); > + omap4_prcm_irq_setup.pm_ctrl); > omap_test_timeout( > (((omap4_prm_read_inst_reg(inst, > -OMAP4_PRM_IO_PMCTRL_OFFSET) & > +omap4_prcm_irq_setup.pm_ctrl) & > OMAP4430_WUCLK_STATUS_MASK) >> > OMAP4430_WUCLK_STATUS_SHIFT) == 1), > MAX_IOPAD_LATCH_TIME, i); > @@ -319,10 +320,10 @@ static void omap44xx_prm_reconfigure_io_chain(void) > /* Trigger WUCLKIN disable */ > omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0, > inst, > - OMAP4_PRM_IO_PMCTRL_OFFSET); > + omap4_prcm_irq_setup.pm_ctrl); > omap_test_timeout( > (((omap4_prm_read_inst_reg(inst, > -OMAP4_PRM_IO_PMCTRL_OFFSET) & > +omap4_prcm_irq_setup.pm_ctrl) & > OMAP4430_WUCLK_STATUS_MASK) >> > OMAP4430_WUCLK_STATUS_SHIFT) == 0), > MAX_IOPAD_LATCH_TIME, i); > @@ -350,7 +351,7 @@ static void __init omap44xx_prm_enable_io_wakeup(void) > omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK, > OMAP4430_GLOBAL_WUEN_MASK, > inst, > - OMAP4_PRM_IO_PMCTRL_OFFSET); > + omap4_prcm_irq_setup.pm_ctrl); > } > > /** > -- > 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
Re: [GIT PULL] clk: ti: clock driver code migration to drivers
On Tue, 14 Jul 2015, Tony Lindgren wrote: > * Tero Kristo [150714 03:34]: > > On 07/14/2015 12:54 PM, Tony Lindgren wrote: > > >* Tero Kristo [150714 01:56]: > > >> > > >>This pull request contains the TI clock driver set to move the clock > > >>implementations under clock driver. Some small portions of the clock > > >>driver > > >>code still remain under mach-omap2 after this, it should be decided > > >>whether > > >>this code is now obsolete and should be deleted or should someone try to > > >>fix > > >>it. > > > > > >Hmm care to clarify what is obsolete or broken after this series? > > > > Not after this series, was broken/obsolete already before. > > > > A couple of omap2/omap3 specific clock files still remain under mach-omap2, > > they are DVFS related. OMAP3 core dvfs support is currently completely > > unused (this could probably be removed, or shall we re-introduce the painful > > core dvfs at some point again?), and parts of the omap2 core dpll handling > > code should probably be re-written; or at least verified that it actually > > works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with > > it I could probably try to get some sort of DVFS test case to work on > > the board farm OMAP2 board I have access to though, I can investigate this. > > People seem to still want the 1 GiHz support, but I think that only > depends on the SmartReflex and some kind of replacement for > voltagedomains. So if the core DVFS support is unused, I doubt it's > very high on anybody's list right now. At least several years ago, basic CORE DVFS support was working on OMAP3. The clock source changed rate, DRAM parameters were changed on the SDRC, etc. What was not implemented was pre-rate-change and post-rate-change notifiers in many of the device drivers, because the infrastructure didn't exist at the time in the clock code. - 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 Roger On Mon, 13 Jul 2015, 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. > > This can potentially cause a bus access error if the module is accessed > before the module is ready. > > Get rid of the redundant _find_mpu_rt_port() check from the > _wait_target_ready() > funcion for all the SoCs. The following PRCM register access that checks the > module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port. > > e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. Could you update this patch to align with the discussion we had the last time this was posted in December? e.g., http://www.spinics.net/lists/arm-kernel/msg388002.html You can ignore the problems with the VAR-SOM-OM that were discussed; those were indeed due to an old DT file in use, as Suman suspected. Let me know if you have any questions about 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 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO
Hi On Tue, 23 Jun 2015, Roger Quadros wrote: > For some hwmods (e.g. DCAN on DRA7) we need the possibility to > disable HW_AUTO for the clockdomain while the module is active. > > To achieve this there needs to be a refcounting mechanism to > indicate whether any module in the clockdomain has requested > to disable HW_AUTO. We keep track of this in 'noidlecount'. > > Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent > HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls. > > It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in > the future clkdm_hwmod_hwauto() calls. > > Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs > to request HW_AUTO of any clockdomain. (Typically after it has > enabled the module). How about just modifying clkdm_{allow,deny}_idle*() to do the idle-block-counting? The default state would be to allow idle, assuming that the clockdomain flags support that state, and then clkdm_deny_idle*() would increment the idle-blocking count, clkdm_allow_idle*() would decrement it. Then on the 0 -> 1 or 1 -> 0 transitions, the hardware would be reprogrammed appropiately. Anyway, seems like that would avoid races with any clkdm_{allow,deny}_idle*() users. A few other comments below: > > Signed-off-by: Roger Quadros > --- > arch/arm/mach-omap2/clockdomain.c | 71 > +++ > arch/arm/mach-omap2/clockdomain.h | 5 +++ > 2 files changed, 76 insertions(+) > > diff --git a/arch/arm/mach-omap2/clockdomain.c > b/arch/arm/mach-omap2/clockdomain.c > index 2da3b5e..a7190d2 100644 > --- a/arch/arm/mach-omap2/clockdomain.c > +++ b/arch/arm/mach-omap2/clockdomain.c > @@ -1212,6 +1212,77 @@ ccd_exit: > return 0; > } > > +/* > + * prevent future hwauto for this clkdm. If clkdm->usecount becomes hwauto > isn't prevented. > + * It will only prevnt future hwauto but not bring it out of hwauto. > + */ If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue - but all of the function comments should be fixed so that they are understandable and follow kernel-doc-nano specs. > +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct omap_hwmod > *oh) > +{ > + /* The clkdm attribute does not exist yet prior OMAP4 */ > + if (cpu_is_omap24xx() || cpu_is_omap34xx()) > + return 0; > + > + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable) > + return -EINVAL; > + > + > + pwrdm_lock(clkdm->pwrdm.ptr); > + clkdm->noidlecount++; > + pwrdm_unlock(clkdm->pwrdm.ptr); > + > + return 0; > +} > + > +/* > + * allow future hwauto for this clkdm > + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that. > + */ > +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod > *oh) > +{ > + /* The clkdm attribute does not exist yet prior OMAP4 */ > + if (cpu_is_omap24xx() || cpu_is_omap34xx()) > + return 0; > + > + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable) > + return -EINVAL; > + > + > + pwrdm_lock(clkdm->pwrdm.ptr); > + > + if (clkdm->noidlecount == 0) { > + pwrdm_unlock(clkdm->pwrdm.ptr); > + WARN_ON(1); /* underflow */ > + return -ERANGE; > + } > + > + clkdm->noidlecount--; > + pwrdm_unlock(clkdm->pwrdm.ptr); > + > + return 0; > +} > + > +/* > + * put clkdm in hwauto if we can. checks noidlecount to see if we can. > + */ > +int clkdm_hwmod_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh) > +{ > + /* The clkdm attribute does not exist yet prior OMAP4 */ > + if (cpu_is_omap24xx() || cpu_is_omap34xx()) > + return 0; > + > + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable) > + return -EINVAL; > + > + > + pwrdm_lock(clkdm->pwrdm.ptr); > + if (clkdm->noidlecount == 0) > + clkdm_allow_idle_nolock(clkdm); > + > + pwrdm_unlock(clkdm->pwrdm.ptr); > + > + return 0; > +} > + > /** > * clkdm_hwmod_enable - add an enabled downstream hwmod to this clkdm > * @clkdm: struct clockdomain * > diff --git a/arch/arm/mach-omap2/clockdomain.h > b/arch/arm/mach-omap2/clockdomain.h > index 77bab5f..8c491be 100644 > --- a/arch/arm/mach-omap2/clockdomain.h > +++ b/arch/arm/mach-omap2/clockdomain.h > @@ -114,6 +114,7 @@ struct omap_hwmod; > * @wkdep_srcs: Clockdomains that can be told to wake this powerdomain up > * @sleepdep_srcs: Clockdomains that can be told to keep this clkdm from > inact > * @usecount: Usecount tracking > + * @noidlecount: Noidle count tracking. Domain won't be auto idled this is > > 0. > * @node: list_head to link all clockdomains together > * > * @prcm_partition should be a macro from mach-omap2/prcm44xx.h (OMAP4 only) > @@ -138,6 +139,7 @@ struct clockdomain { > struct clkdm_dep *wkdep_srcs; > struct clkdm_dep *sleepdep_srcs; > int usecount; > + int n
Re: [PATCH 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks
On Tue, 14 Jul 2015, Tero Kristo wrote: > On 07/14/2015 01:09 PM, Lokesh Vutla wrote: > > Hi, > > On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote: > > > Some IP blocks like RTC, needs an additional unlocking mechanism for > > > writing to its registers. This patch adds optional lock and unlock > > > function pointers to the IP block's hwmod data which gets executed > > > before and after writing into IP sysconfig register. > > > And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod data, > > > so that sysconfig registers are updated properly. > > ping on this series. > > > > Thanks and regards, > > Lokesh > [...] > It is also racy, as there is no locking in place to avoid concurrent access to > the lock/unlock registers across hwmod+driver. I don't see the race. Where is 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 3/3] ARM: AMx3xx: hwmod: RTC: Add lock and unlock functions
Hi On Wed, 10 Jun 2015, 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 to be > written to KICK registers. > > omap_hwmod_rtc_unlock/lock functions writes into these KICK registers > inorder to lock and unlock RTC registers. > This patch hooks omap_hwmod_rtc_unlock/lock functions into RTC hwmod, > so that SYSCONFIG register is updated properly. > > Signed-off-by: Lokesh Vutla > --- > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c > b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c > index cabc569..2d92958 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c > @@ -904,6 +904,8 @@ static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc > = { > static struct omap_hwmod_class am33xx_rtc_hwmod_class = { > .name = "rtc", > .sysc = &am33xx_rtc_sysc, > + .unlock = &omap_hwmod_rtc_unlock, > + .lock = &omap_hwmod_rtc_lock, > }; > > struct omap_hwmod am33xx_rtc_hwmod = { The DRA7xx integration from the previous patch should either be combined with this patch, or moved into a separate patch like this one (your preference). - 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/3] ARM: DRA: hwmod: RTC: Add lock and unlock functions
Hi, some comments. On Wed, 10 Jun 2015, 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 to be > written to KICK registers. > > Introduce omap_hwmod_rtc_unlock/lock functions, which writes into these > KICK registers inorder to lock and unlock RTC registers. > Also hook these functions to RTC hwmod. > > Signed-off-by: Lokesh Vutla > --- > arch/arm/mach-omap2/omap_hwmod.h | 2 ++ > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++ > arch/arm/mach-omap2/omap_hwmod_reset.c| 47 > +++ > 3 files changed, 51 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod.h > b/arch/arm/mach-omap2/omap_hwmod.h > index 44c7db9..04855ab 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.h > +++ b/arch/arm/mach-omap2/omap_hwmod.h > @@ -742,6 +742,8 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod > *oh); > */ > > extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh); > +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh); > +void omap_hwmod_rtc_lock(struct omap_hwmod *oh); > > /* > * Chip variant-specific hwmod init routines - XXX should be converted > diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > index 0e64c2f..983042f 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > @@ -1548,6 +1548,8 @@ static struct omap_hwmod_class_sysconfig > dra7xx_rtcss_sysc = { > static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = { > .name = "rtcss", > .sysc = &dra7xx_rtcss_sysc, > + .unlock = &omap_hwmod_rtc_unlock, > + .lock = &omap_hwmod_rtc_lock, > }; > > /* rtcss */ Is the DRA7xx the only chip that has this lock/unlock feature, or do other OMAP chips use the same RTC IP block? > diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c > b/arch/arm/mach-omap2/omap_hwmod_reset.c > index 65e186c..1fb106d 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_reset.c > +++ b/arch/arm/mach-omap2/omap_hwmod_reset.c > @@ -25,11 +25,20 @@ > */ > #include > #include > +#include > > #include > > #include "omap_hwmod.h" > > +#define OMAP_RTC_STATUS_REG 0x44 > +#define OMAP_RTC_KICK0_REG 0x6c > +#define OMAP_RTC_KICK1_REG 0x70 > + > +#define OMAP_RTC_KICK0_VALUE 0x83E70B13 > +#define OMAP_RTC_KICK1_VALUE 0x95A4F1E0 > +#define OMAP_RTC_STATUS_BUSY BIT(0) > + > /** > * omap_hwmod_aess_preprogram - enable AESS internal autogating > * @oh: struct omap_hwmod * > @@ -51,3 +60,41 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh) > > return 0; > } > + > +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh) This function is missing kerneldoc and desperately needs it. > +{ > + int count; > + u8 status; > + > + /* BUSY may stay active for 1/32768 second (~30 usec) */ > + for (count = 0; count < 50; count++) { OK, I give up. Where does 50 come from? This should be moved into a macro with a comment, at the very least. > + status = omap_hwmod_read(oh, OMAP_RTC_STATUS_REG); > + if (!(status & OMAP_RTC_STATUS_BUSY)) > + break; > + udelay(1); > + } > + /* now we have ~15 usec to read/write various registers */ > +} > + > +/** > + * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism. > + * @oh: struct omap_hwmod * > + * > + * RTC IP have kicker feature. This prevents spurious writes to its > registers. > + * In order to write into any of the RTC registers, KICK values has te be > + * written in respective KICK registers. This is needed for hwmod to write > into > + * sysconfig register. > + */ > +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh) > +{ > + omap_rtc_wait_not_busy(oh); What prevents the CPU from context-switching away after the BUSY bit test and not returning back here by the time the ~15 µs interval has ended? Looks to me like this whole thing needs to run with interrupts disabled. > + omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG); > + omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG); > +} > + > +void omap_hwmod_rtc_lock(struct omap_hwmod *oh) > +{ > + omap_rtc_wait_not_busy(oh); Same comment as the above. > + omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG); > + omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG); > +} > -- > 1.9.1 > - Paul
Re: [PATCH 1/3] ARM: OMAP2+: hwmod: add support for lock and unlock hooks
On Wed, 10 Jun 2015, Lokesh Vutla wrote: > Some IP blocks like RTC, needs an additional setting for writing to its > registers. This is to prevent any spurious writes from changing the > register values. > > This patch adds optional lock and unlock function pointers to > the IP block's hwmod data. These unlock and lock function pointers > are called by hwmod code before and after writing sysconfig registers. > > Signed-off-by: Lokesh Vutla Thanks, queued for v4.3. - 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 1/1] ARM: DRA7: hwmod: fix gpmc hwmod
On Wed, 8 Jul 2015, Roger Quadros wrote: > GPMC smart idle is not really broken but it does not support > smart idle with wakeup. > > Fixes: 556708fe8718 ("ARM: OMAP: DRA7: hwmod: Make gpmc software supervised > as the smart idle is broken") > > Signed-off-by: Roger Quadros Thanks Roger, queued for v4.2-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 v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
Hi, some comments. On Wed, 3 Jun 2015, Vignesh R wrote: > Add hwmod entries for the PWMSS on DRA7. > > Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock > equal to L4PER2_L3_GICLK/2(l3_iclk_div/2). > As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4, > clock source to PWMSS is L4PER2_L3_GICLK. But it is actually > L4PER2_L3_GICLK/2. The TRM does not show the division by 2. Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]? Or is HSPCLKDIV a separate divider after the divide-by-2 you mention above? > [1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf > > Signed-off-by: Vignesh R > --- > > v2: > * add TRM references. > > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 > ++ > 1 file changed, 239 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > index 0e64c2fac0b5..86a7ac9a3138 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c > @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = { > }, > }; > > +/* pwmss */ > +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = { > + .rev_offs = 0x0, > + .sysc_offs = 0x4, > + .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS, This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG". There's no RESETSTATUS bit. There is a SOFTRESET bit. Could you please confirm whether this is intentional? > + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), > + .sysc_fields= &omap_hwmod_sysc_type2, > +}; > + > +struct omap_hwmod_class dra7xx_epwmss_hwmod_class = { > + .name = "epwmss", > + .sysc = &dra7xx_epwmss_sysc, > +}; > + > +static struct omap_hwmod_class dra7xx_ecap_hwmod_class = { > + .name = "ecap", > +}; > + > +static struct omap_hwmod_class dra7xx_eqep_hwmod_class = { > + .name = "eqep", > +}; > + > +struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = { > + .name = "ehrpwm", > +}; > + > +/* epwmss0 */ > +struct omap_hwmod dra7xx_epwmss0_hwmod = { > + .name = "epwmss0", > + .class = &dra7xx_epwmss_hwmod_class, > + .clkdm_name = "l4per2_clkdm", > + .main_clk = "l4_root_clk_div", > + .prcm = { > + .omap4 = { > + .modulemode = MODULEMODE_SWCTRL, > + .clkctrl_offs = > DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET, > + .context_offs = > DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET, > + }, > + }, Per my comment on the previous patch, sounds like it might be better to mark this as HWMOD_SWSUP_SIDLE? Then again, see the next comment below re: main_clk. > +}; > + > +/* ecap0 */ > +struct omap_hwmod dra7xx_ecap0_hwmod = { > + .name = "ecap0", > + .class = &dra7xx_ecap_hwmod_class, > + .clkdm_name = "l4per2_clkdm", > + .main_clk = "l4_root_clk_div", Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", there appears to be a local "mini-PRCM" for the PWMSS which implements clock gating and reports back on the status of what I'd guess is the local clock gating FSM. So from that point of view, you should probably create a clock driver that manages both the clock gate request bit and the FSM status bit. It should be something that can be reused for the other PWMSS IP blocks. Then you'd create per-IP block clock nodes and set the main_clk to point to that node. > +}; > + > +/* eqep0 */ > +struct omap_hwmod dra7xx_eqep0_hwmod = { > + .name = "eqep0", > + .class = &dra7xx_eqep_hwmod_class, > + .clkdm_name = "l4per2_clkdm", > + .main_clk = "l4_root_clk_div", Same main_clk comments as for ecap0. > +}; > + > +/* ehrpwm0 */ > +struct omap_hwmod dra7xx_ehrpwm0_hwmod = { > + .name = "ehrpwm0", > + .class = &dra7xx_ehrpwm_hwmod_class, > + .clkdm_name = "l4per2_clkdm", > + .main_clk = "l4_root_clk_div", Same main_clk comments as for ecap0. > +}; > + > +/* epwmss1 */ > +struct omap_hwmod dra7xx_epwmss1_hwmod = { > + .name = "epwmss1", > + .class = &dra7xx_epwmss_hwmod_class, > + .clkdm_name = "l4per2_clkdm", > + .main_clk = "l4_root_clk_div", > + .prcm = { > + .omap4 = { > + .modulemode = MODULEMODE_SWCTRL, > + .clkctrl_offs = > DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL_OFFSET, > + .context_offs = > DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET, > + }, > + }, Same flags comment as for epwmss0. > +}; > + > +/* ecap1 */ > +struct omap_hwmod dra7xx_ecap1_hwmod = { > + .name = "ecap1", > + .class = &dra7xx_ecap_hwmod_class, > + .clkdm_name =
Re: [PATCH v2 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
On Wed, 15 Jul 2015, Paul Walmsley wrote: > On Wed, 3 Jun 2015, Vignesh R wrote: > > > Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support > > smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence, > > program clock domain to SW_WKUP. > > > > Signed-off-by: Vignesh R > > --- > > arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c > > b/arch/arm/mach-omap2/clockdomains7xx_data.c > > index 57d5df0c1fbd..7581e036bda6 100644 > > --- a/arch/arm/mach-omap2/clockdomains7xx_data.c > > +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c > > @@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = { > > .dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT, > > .wkdep_srcs = l4per2_wkup_sleep_deps, > > .sleepdep_srcs= l4per2_wkup_sleep_deps, > > - .flags= CLKDM_CAN_HWSUP_SWSUP, > > + .flags= CLKDM_CAN_SWSUP, > > }; > > > > static struct clockdomain mpu0_7xx_clkdm = { > > Thanks, queued for v4.2-rc fixes. Note that I cannot test this, since I > don't have a DRA7xx board. You know, upon further thought, this doesn't make sense. If the bug is with the PWMSS IP block specifically, why not just set HWMOD_SWSUP_SIDLE on all the IP blocks where the hardware folks didn't implement hardware smart-idle? At least that way, if those legacy IP blocks aren't in use, the clockdomain can still enter hardware-supervised idle? This patch basically disables hardware-supervised/smart idle for all of the IP blocks in that clockdomain? - 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 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
On Wed, 3 Jun 2015, Vignesh R wrote: > Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support > smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence, > program clock domain to SW_WKUP. > > Signed-off-by: Vignesh R > --- > arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c > b/arch/arm/mach-omap2/clockdomains7xx_data.c > index 57d5df0c1fbd..7581e036bda6 100644 > --- a/arch/arm/mach-omap2/clockdomains7xx_data.c > +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c > @@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = { > .dep_bit = DRA7XX_L4PER2_STATDEP_SHIFT, > .wkdep_srcs = l4per2_wkup_sleep_deps, > .sleepdep_srcs= l4per2_wkup_sleep_deps, > - .flags= CLKDM_CAN_HWSUP_SWSUP, > + .flags= CLKDM_CAN_SWSUP, > }; > > static struct clockdomain mpu0_7xx_clkdm = { Thanks, queued for v4.2-rc fixes. 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 v4.2-rc2
Here are some basic OMAP test results for Linux v4.2-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc2/20150714130012/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.2-rc1 (d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754)): text data bsstotal kernel +5700 +57 omap1_defconfig +6900 +69 omap1_defconfig_1510innovator_only +5700 +57 omap1_defconfig_5912osk_only +403 +4160 +819 multi_v7_defconfig +500 +5 omap2plus_defconfig +58500 +585 omap2plus_defconfig_2430sdp_only +10100 +101 omap2plus_defconfig_am33xx_only +10100 +101 omap2plus_defconfig_am43xx_only +410100+4101 omap2plus_defconfig_cpupm +419300+4193 omap2plus_defconfig_dra7xx_only +28900 +289 omap2plus_defconfig_n800_multi_omap2xxx +21300 +213 omap2plus_defconfig_n800_only_a +420500+4205 omap2plus_defconfig_no_pm +7700 +77 omap2plus_defconfig_omap2_4_only +2500 +25
OMAP baseline test results for v4.2-rc1
Here are some basic OMAP test results for Linux v4.2-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.2-rc1/20150705171039/ 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-stk-om44, 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: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, 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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 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: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1 (b953c0d234bc72e8489d3bf51a276c5c4ec85345)): text data bsstotal kernel +49744 -60136 +10456 +64 omap1_defconfig +48684 -60136 +10456 -996 omap1_defconfig_1510innovator_only +49752 -56296 +10520+3976 omap1_defconfig_5912osk_only -319515 +45664+8640 -265211 multi_v7_defconfig +94414-8216+4992 +91190 omap2plus_defconfig +85692+4432+4856 +94980 omap2plus_defconfig_2430sdp_only +106074+5320+4928 +116322 omap2plus_defconfig_am33xx_only +101982+5448+4992 +112422 omap2plus_defconfig_am43xx_only +94414-8216+4928 +91126 omap2plus_defconfig_cpupm +103166+6472+4928 +114566 omap2plus_defconfig_dra7xx_only +37781+3952+4736 +46469 omap2plus_defconfig_n800_multi_omap2xxx +12695+3928+4200 +20823 omap2plus_defconfig_n800_only_a +92086-7392+5056 +89750 omap2plus_defconfig_no_pm +106498+6504+4864 +117866 omap2plus_defconfig_omap2_4_only +97350 -12312+4928 +89966 om
OMAP baseline test results for v4.1
Here are some basic OMAP test results for Linux v4.1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1/20150626170101/ 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-stk-om44, 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 (14/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 Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 3730es12beaglexm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 3730es12beaglexm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm 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: FAIL ( 2/ 4): 37xxevm, 3730es12beaglexm Pass ( 2/ 4): 3530es3beagle, 3530es31beagle PM: chip off via dynamic idle: FAIL ( 2/ 4): 37xxevm, 3730es12beaglexm Pass ( 2/ 4): 3530es3beagle, 3530es31beagle Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc8 (0f57d86787d8b1076ea8f9cba2a46d534a27)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0 +80 +8 omap1_defconfig_5912osk_only -3200 -32 multi_v7_defconfig +6400 +64 omap2plus_defconfig +3200 +32 omap2plus_defconfig_2430sdp_only +6400 +64 omap2plus_defconfig_am33xx_only +6400 +64 omap2plus_defconfig_am43xx_only +6400 +64 omap2plus_defconfig_cpupm +6400 +64 omap2plus_defconfig_dra7xx_only -64
OMAP baseline test results for v4.1-rc8
Here are some basic OMAP test results for Linux v4.1-rc8. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc8/20150621202355/ 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-stk-om44, 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 (14/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 Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, 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 ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc7 (d4a4f75cd8f29cd9464a5a32e9224a91571d6649)): text data bsstotal kernel +8800 +88 omap1_defconfig +8000 +80 omap1_defconfig_1510innovator_only +80 -80 +72 omap1_defconfig_5912osk_only -20000 -200 multi_v7_defconfig +20800 +208 omap2plus_defconfig +17600 +176 omap2plus_defconfig_2430sdp_only +20800 +208 omap2plus_defconfig_am33xx_only +20800 +208 omap2plus_defconfig_am43xx_only +20800 +208 omap2plus_defconfig_cpupm +20800 +208
OMAP baseline test results for v4.1-rc7
Here are some basic OMAP test results for Linux v4.1-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc7/20150607230110/ 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-stk-om44, 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 (14/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 Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, 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 ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc6 (c65b99f046843d2455aa231747b5a07a999a9f3d)): text data bsstotal kernel +57 +320 +89 omap1_defconfig +6500 +65 omap1_defconfig_1510innovator_only +6500 +65 omap1_defconfig_5912osk_only +497 -80 +489 multi_v7_defconfig +209 -960 +113 omap2plus_defconfig +185 -1120 +73 omap2plus_defconfig_2430sdp_only +145 -960 +49 omap2plus_defconfig_am33xx_only +141 -960 +45 omap2plus_defconfig_am43xx_only +273 -880 +185 omap2plus_defconfig_cpupm +141 -880 +53
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Hi Jeroen, On Sun, 7 Jun 2015, Paul Walmsley wrote: > On Sun, 7 Jun 2015, Jeroen Hofstee wrote: > > > On 05-06-15 10:04, Jeroen Hofstee wrote: > > > > > > On 05-06-15 10:01, Jeroen Hofstee wrote: > > > > > > > > On 01-06-15 19:44, Paul Walmsley wrote: > > > > > The best way to make this work IMHO would be for us not to accept any > > > > > new > > > > > feature addition patches as long as there are warnings reported in the > > > > > test results. The only real exception that I would foresee is if > > > > > those > > > > > warnings are due to something outside of our control, e.g., a crappy > > > > > bootloader, as I suspect the USB_OTG initiator warnings are for the > > > > > CM-T3517. > > > > > > > > > > > > > I doubt this is related to the bootloader. I have the suspicion that is > > > > actually > > > > a bug in linux but only triggered depending on whether the ROMcode setup > > > > the USB OTG or not. Here is some data to backup my statement: > > > > > > > > Turns out my suspicion was wrong. This is what I know at the moment, > > depending on the bootpins, u-boot will trigger a bad access when loading > > a file over ethernet, but only the first time. Clearing the pending > > interrupt > > before booting linux make the "USB_OTG address hole seen" go away. > > Oh, too bad. I had been hoping that you were right and that I was wrong > ;-) I'll try this on the CM-T3517 here. I used your debugging technique here and was able to reproduce your results - with one difference: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150607194102/boot/cmt3517/cmt3517_log.txt The interconnect error was logged upon the first interaction with the network. In my case this was with the U-boot 'dhcp' command. The pending interrupt bit was cleared before loading the kernel via tftp, and the interrupt bit was not set again, even after a tftp load. 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: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Hi Jeroen, On Sun, 7 Jun 2015, Jeroen Hofstee wrote: > Hello Paul, > > On 05-06-15 10:04, Jeroen Hofstee wrote: > > > > On 05-06-15 10:01, Jeroen Hofstee wrote: > > > > > > On 01-06-15 19:44, Paul Walmsley wrote: > > > > The best way to make this work IMHO would be for us not to accept any > > > > new > > > > feature addition patches as long as there are warnings reported in the > > > > test results. The only real exception that I would foresee is if those > > > > warnings are due to something outside of our control, e.g., a crappy > > > > bootloader, as I suspect the USB_OTG initiator warnings are for the > > > > CM-T3517. > > > > > > > > > > I doubt this is related to the bootloader. I have the suspicion that is > > > actually > > > a bug in linux but only triggered depending on whether the ROMcode setup > > > the USB OTG or not. Here is some data to backup my statement: > > > > > Turns out my suspicion was wrong. This is what I know at the moment, > depending on the bootpins, u-boot will trigger a bad access when loading > a file over ethernet, but only the first time. Clearing the pending interrupt > before booting linux make the "USB_OTG address hole seen" go away. Oh, too bad. I had been hoping that you were right and that I was wrong ;-) I'll try this on the CM-T3517 here. I'd like to solicit your opinion on what to do here. I wonder if, in the L3 bus drivers, we should simply report, in a line or two, if any bus errors were logged before the kernel starts? That would help discriminate between problems that the kernel is responsible for, vs. problems that occur earlier in the boot process. Any thoughts? Thanks for all your investigation, by the way, it's much appreciated. regards, - Paul > > Regards, > Jeroen > > U-Boot 2015.04-00098-g487ee34-dirty (Jun 05 2015 - 13:14:48) > > AM35XX-GP ES2.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 Mhz > ccgx + LPDDR/NAND > I2C: ready > DRAM: 256 MiB > NAND: 512 MiB > MMC: OMAP SD/MMC: 0 > In:serial > Out: serial > Err: serial > Die ID #22760001014e0fb21500b024 > Net: DaVinci-EMAC > Hit any key to stop autoboot: 0 > ccgx=> echo $clear_l3_int > mw 68004428 0x1100; mw 6800442C 0x; mw 68004458 0x; mw > 6800445C 0x > ccgx=> md 0x68000510 2 > 68000510: > ccgx=> tftp ccgx/zImage; tftp 8000 ccgx/am3517-ccgx.dtb; > Using DaVinci-EMAC device > TFTP from server 10.0.0.103; our IP address is 10.0.0.250 > Filename 'ccgx/zImage'. > Load address: 0x8030 > Loading: # > # > # > # > # > # > # > # > # > # > # > # > ## > 863.3 KiB/s > done > Bytes transferred = 4040072 (3da588 hex) > Using DaVinci-EMAC device > TFTP from server 10.0.0.103; our IP address is 10.0.0.250 > Filename 'ccgx/am3517-ccgx.dtb'. > Load address: 0x8000 > Loading: ### > 825.2 KiB/s > done > Bytes transferred = 54112 (d360 hex) > ccgx=> md 0x68000510 2 > 68000510: 0400 > ccgx=> run clear_l3_int > ccgx=> md 0x68000510 2 > 68000510: > ccgx=> boot > > # USB_OTG error is gone... > -- 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 1/2] clk: change clk_ops' ->round_rate() prototype
Hi folks just a brief comment on this one: On Thu, 30 Apr 2015, Boris Brezillon wrote: > Clock rates are stored in an unsigned long field, but ->round_rate() > (which returns a rounded rate from a requested one) returns a long > value (errors are reported using negative error codes), which can lead > to long overflow if the clock rate exceed 2Ghz. > > Change ->round_rate() prototype to return 0 or an error code, and pass the > requested rate as a pointer so that it can be adjusted depending on > hardware capabilities. ... > diff --git a/Documentation/clk.txt b/Documentation/clk.txt > index 0e4f90a..fca8b7a 100644 > --- a/Documentation/clk.txt > +++ b/Documentation/clk.txt > @@ -68,8 +68,8 @@ the operations defined in clk.h: > int (*is_enabled)(struct clk_hw *hw); > unsigned long (*recalc_rate)(struct clk_hw *hw, > unsigned long parent_rate); > - long(*round_rate)(struct clk_hw *hw, > - unsigned long rate, > + int (*round_rate)(struct clk_hw *hw, > + unsigned long *rate, > unsigned long *parent_rate); > long(*determine_rate)(struct clk_hw *hw, > unsigned long rate, I'd suggest that we should probably go straight to 64-bit rates. There are already plenty of clock sources that can generate rates higher than 4GiHz. - 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: DRA7: hwmod: Fix GPMC from preventing core suspend
On Tue, 2 Jun 2015, Roger Quadros wrote: > GPMC hwmod is flagged as HWMOD_INIT_NO_IDLE so it is kept > enabled at boot. If the GPMC driver is not loaded then > GPMC will not be idled thus preventing CORE from going idle > during suspend. > > Disable HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET. > > The only reason HWMOD_INIT_NO_RESET was there was to retain > GPMC timings/settings configured by bootloader. We no longer > need that as we're configuring the timins in the kernel. > > There is no reasoning as to why HWMOD_INIT_NO_IDLE was there. > Seems to have beein blindly copied from omap3/4 hwmod code. > > Signed-off-by: Roger Quadros Hi Roger, could you take a look at Tony's patch "memory: omap-gpmc: Add Kconfig option for debug" and see if this needs to be changed in light of that patch? 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: [PATCH 1/2] ARM: DRA7: hwmod: fix gpmc hwmod
On Tue, 2 Jun 2015, Roger Quadros wrote: > GPMC smart idle is not really broken but it does not support > smart idle with wakeup. > > Fixes: 556708fe8718 ("ARM: OMAP: DRA7: hwmod: Make gpmc software supervised > as the smart idle is broken") > > Signed-off-by: Roger Quadros Thanks, queued for v4.2-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: Regression with AM43xx devices
On Tue, 2 Jun 2015, Felipe Balbi wrote: > You commit fabbe6df130a46d5b5e7484b2273d69c4be3012a (ARM: OMAP: AM43xx > hwmod: Add data for am43xx emif hwmod) listed below added a new WARNING > during boot to all AM43xx-based boards. Full boot logs can be found at > [1], Speaking of which, could you guys please send along an AM43xx board for the testbed? That would help avoid these issues earlier. - 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: OMAP: AM43xx hwmod: Add data for am43xx emif hwmod
On Wed, 6 May 2015, Dave Gerlach wrote: > Without a hwmod for am43xx emif use counting for emif clockdomain does > not happen correctly so it may be shut off by pm code unintentionally. > > Signed-off-by: Dave Gerlach Thanks, sent upstream for v4.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 02/10] ARM: OMAP3: Fix crypto support for HS devices
On Tue, 26 May 2015, Pali Rohár wrote: > Hi Paul, > > this patch is also for omap2... Can you review it too? > > On Saturday 28 February 2015 17:24:36 Pavel Machek wrote: > > On Thu 2015-02-26 14:49:52, Pali Rohár wrote: > > > Register crypto hwmod links only if they are not disabled in DT. > > > If DT information is missing, enable them only for GP devices. > > > > > > Before this patch crypto hwmod links were always disabled for all HS > > > devices > > > and it was not possible to use omap-aes and omap-sham linux drivers. > > > > > > Signed-off-by: Pali Rohár > > > > Acked-by: Pavel Machek > > Sent to Tony for v4.2, after tweaking it a bit (below) - Paul Subject: [PATCH] ARM: OMAP3: Fix crypto support for HS devices Register crypto hwmod links only if they are not disabled in DT. If DT information is missing, enable them only for GP devices. Before this patch crypto hwmod links were always disabled for all HS devices and it was not possible to use omap-aes and omap-sham linux drivers. Signed-off-by: Pali Rohár Acked-by: Pavel Machek [p...@pwsan.com: move the complex IP-block presence heuristics into their own function to simplify the code; fix some checkpatch warnings] Signed-off-by: Paul Walmsley --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 107 + 1 file changed, 94 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index 0ca4d3fb7df6..dc55f8dedf2c 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -3736,29 +3736,54 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = { /* GP-only hwmod links */ static struct omap_hwmod_ocp_if *omap34xx_gp_hwmod_ocp_ifs[] __initdata = { &omap3xxx_l4_sec__timer12, - &omap3xxx_l4_core__sham, - &omap3xxx_l4_core__aes, NULL }; static struct omap_hwmod_ocp_if *omap36xx_gp_hwmod_ocp_ifs[] __initdata = { &omap3xxx_l4_sec__timer12, - &omap3xxx_l4_core__sham, - &omap3xxx_l4_core__aes, NULL }; static struct omap_hwmod_ocp_if *am35xx_gp_hwmod_ocp_ifs[] __initdata = { &omap3xxx_l4_sec__timer12, - /* -* Apparently the SHA/MD5 and AES accelerator IP blocks are -* only present on some AM35xx chips, and no one knows which -* ones. See -* http://www.spinics.net/lists/arm-kernel/msg215466.html So -* if you need these IP blocks on an AM35xx, try uncommenting -* the following lines. -*/ + NULL +}; + +/* crypto hwmod links */ +static struct omap_hwmod_ocp_if *omap34xx_sham_hwmod_ocp_ifs[] __initdata = { + &omap3xxx_l4_core__sham, + NULL +}; + +static struct omap_hwmod_ocp_if *omap34xx_aes_hwmod_ocp_ifs[] __initdata = { + &omap3xxx_l4_core__aes, + NULL +}; + +static struct omap_hwmod_ocp_if *omap36xx_sham_hwmod_ocp_ifs[] __initdata = { + &omap3xxx_l4_core__sham, + NULL +}; + +static struct omap_hwmod_ocp_if *omap36xx_aes_hwmod_ocp_ifs[] __initdata = { + &omap3xxx_l4_core__aes, + NULL +}; + +/* + * Apparently the SHA/MD5 and AES accelerator IP blocks are + * only present on some AM35xx chips, and no one knows which + * ones. See + * http://www.spinics.net/lists/arm-kernel/msg215466.html So + * if you need these IP blocks on an AM35xx, try uncommenting + * the following lines. + */ +static struct omap_hwmod_ocp_if *am35xx_sham_hwmod_ocp_ifs[] __initdata = { /* &omap3xxx_l4_core__sham, */ + NULL +}; + +static struct omap_hwmod_ocp_if *am35xx_aes_hwmod_ocp_ifs[] __initdata = { /* &omap3xxx_l4_core__aes, */ NULL }; @@ -3860,10 +3885,41 @@ static struct omap_hwmod_ocp_if *omap3xxx_dss_hwmod_ocp_ifs[] __initdata = { NULL }; +/** + * omap3xxx_hwmod_is_hs_ip_block_usable - is a security IP block accessible? + * @bus: struct device_node * for the top-level OMAP DT data + * @dev_name: device name used in the DT file + * + * Determine whether a "secure" IP block @dev_name is usable by Linux. + * There doesn't appear to be a 100% reliable way to determine this, + * so we rely on heuristics. If @bus is null, meaning there's no DT + * data, then we only assume the IP block is accessible if the OMAP is + * fused as a 'general-purpose' SoC. If however DT data is present, + * test to see if the IP block is described in the DT data and set to + * 'status = "okay"'. If so then we assume the ODM has configured the + * OMAP firewalls to allow access to the IP block. + * + * Return: 0 if device named @dev_name is not likely to be accessible, + * or 1 if it is likely to be accessible. + */ +static int __init omap3xxx_hwmod_is_hs_ip_block
[GIT PULL] ARM: OMAP2+: hwmod code and data changes for v4.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118: Linux 4.1-rc4 (2015-05-18 10:13:47 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.2/omap-hwmod-a for you to fetch changes up to a55a744582e0dc106537ba5e508c340c39cfe454: ARM: OMAP3: Fix crypto support for HS devices (2015-06-01 19:23:04 -0600) The branch contains a AM43xx hwmod data change, and thus is based on v4.1-rc4 to avoid merge conflicts. - ARM: OMAP2+: hwmod code and data changes for v4.2 Several OMAP2+ hwmod changes for v4.2. One patch cleans up a nasty interaction between the OMAP GPMC and the hwmod code when debugging is enabled. IP block integration data has been added for the AM43xx EMIF RAM controller. There's also a fix for the omap-aes driver when used in QEMU. And finally, some changes to the OMAP3 hwmod code to support the use of the security IP blocks (AES and SHA) on GP devices, or when they've specifically been enabled in the DT data. Basic build, boot, and power management test results are here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v4.2/20150601192349/ - Dave Gerlach (1): ARM: OMAP: AM43xx hwmod: Add data for am43xx emif hwmod Pali Rohár (2): ARM: OMAP2+: Return correct error values from device and hwmod ARM: OMAP3: Fix crypto support for HS devices Tony Lindgren (1): memory: omap-gpmc: Add Kconfig option for debug arch/arm/mach-omap2/omap_device.c | 30 +++--- arch/arm/mach-omap2/omap_hwmod.c | 10 +- arch/arm/mach-omap2/omap_hwmod.h | 6 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 12 +-- .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 1 + .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 16 ++- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 13 --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 119 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 22 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 11 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 4 +- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 2 + arch/arm/mach-omap2/prcm43xx.h | 2 + drivers/memory/Kconfig | 8 ++ drivers/memory/omap-gpmc.c | 6 +- 15 files changed, 184 insertions(+), 78 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVbSEcAAoJEMePsQ0LvSpLTiwP/2dv6NKgLL2PoXkyqcMcHdcI /zlh8mGH6yaia8jsNZ09Tf6lqZpsIr8FIOZAxq/kx21PhfQ89AcPDYAILmEB1DGk x3/Z6rl26SgZ2HOgjs95FzJYjxy1T48BgZve9rVa/oKlkXdQ6CIdl9rP1SLwLAla Cw++IwfBMr95y+71ov+6Tvit5UmMgCnjCsrcjK0RWUdeVps9Kye8HvWMBLMq7NB2 Tif9S7QGXVFIdPGsOL2ADeC/dvshgSjGsGkQWLi8bkJX92AfU2+WobdZ1aZlKJj+ e8+hj+hVwOLbIYCDPqG14r5z1cVCkoNDvb81J/XTszKTYEcr1d5Z9UgAJkj0kdyb zv41VKL7WxWw7R0biwDlC7XkLD7Ob57ZL3BJ3yMNT7T4dzaJxX8nvwWN0c1OBMXG LyhDm10pPWyy9SAKDczh35veL0EQEMSMt6HUGx9h+fhyU3Sw/XUHzO13l7AWxnIu s0JWYuzk89YXN6q3vBK3OWBe0oQXd7rxKigQ3w2BZ7Squ9jWqIka3vphuwx+UNZ+ UU+wv2+/3gHkzoPFSsVB4C7O3oI07A5HjHegDbPdyaEDq5Bv4Ri7t38+DyKzuZs6 L7J1kMD/xa8XoFHnLuX1cv9k3PPTpkYxxGJOmkhRZ3XVfpqxKYi34uvKkJbHnD7E jDycRKMnfuDOWsqpinJ9 =AOYe -END PGP SIGNATURE-
Re: [PATCHv4 05/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods
On Mon, 1 Jun 2015, Tomi Valkeinen wrote: > Set DSS core hwmod as the parent for all the DSS submodules. > > Signed-off-by: Tomi Valkeinen Acked-by: Paul Walmsley By the way, for commits like this one, it would be nice to add a line describing why the change is needed to the commit message. Something like "This ensures that the parent hwmods are enabled before any DSS submodules are accessed." Tony, feel free to add that to the commit message if you think it's useful. - 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: [PATCHv4 04/10] ARM: DRA7: hwmod: add DMM hwmod description
On Mon, 1 Jun 2015, Tomi Valkeinen wrote: > Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5. > > Signed-off-by: Tomi Valkeinen Acked-by: Paul Walmsley - 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: dts: AM35xx: fix system control module clocks
On Mon, 1 Jun 2015, Tony Lindgren wrote: > * Tony Lindgren [150601 11:06]: > > * Paul Walmsley [150601 10:45]: > > > > > > See for example the "Build warnings from toolchain", "Kernel warnings > > > during boot to userspace", "Kernel warnings during PM test", and > > > "Obsolete > > > Kconfig symbols" sections here: > > > > > > http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt > > > > OK somehow 3517evm is listed under "skip" there? > > Oh I see you have two 3517 devices there, never mind. > > Hmm now I'm wondering what the panda es warnings listed there are.. http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/boot/4430es2panda/4430es2panda_log.txt Looked to me like an OMAP4430 ES2.2 bug. I recall discussing it with someone with an ES2.3 Pandaboard and they said it didn't show up. So I asked TI at the time if there was an erratum for it; apparently not. So I think we may need to add in another hardware bug workaround flag to the OMAP integration code... - 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: dts: AM35xx: fix system control module clocks
On Mon, 1 Jun 2015, Tony Lindgren wrote: > * Paul Walmsley [150601 10:45]: > > > http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt > > OK somehow 3517evm is listed under "skip" there? Yep that board is down right now; something's wrong with it and I haven't had the time to figure out whether it's fixable, or if it's fried. > > The best way to make this work IMHO would be for us not to accept any new > > feature addition patches as long as there are warnings reported in the > > test results. The only real exception that I would foresee is if those > > warnings are due to something outside of our control, e.g., a crappy > > bootloader, as I suspect the USB_OTG initiator warnings are for the > > CM-T3517. > > Right. Also seems we should diff dmesg output too (after stripping out > the timestamps). Pretty much the only things that should change are > the sysfs paths for devices in the dmesg output unless some warnings > get fixed. That output probably still also needs to be manually looked > at though.. Yep, there are still some other minor loose ends to be tied up too that don't show up as full warnings, such as the broken UART4 idle protocol integration on AM35xx... - 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: dts: AM35xx: fix system control module clocks
On Mon, 1 Jun 2015, Tony Lindgren wrote: > * Jeroen Hofstee [150601 09:58]: > > On 01-06-15 17:30, Tero Kristo wrote: > > >New system control module layout for omap3 overlooked parts of the am35xx > > >configuration. Basically the am35xx clocks were not converted to use the > > >changed offsets, which caused weird boot warnings. The errors were not > > >fatal so far, so they were not caught earlier. Fixed by applying the > > >proper offsets for the AM35xx scm clocks. > > > > > >Fixes: b8845074cf ("ARM: dts: omap3: add minimal l4 bus layout with...") > > > > > >Signed-off-by: Tero Kristo > > >Reported-by: Jeroen Hofstee > > >Cc: Paul Walmsley > > >Cc: Tony Lindgren > > >--- > > > arch/arm/boot/dts/am35xx-clocks.dtsi | 14 +++--- > > > 1 file changed, 7 insertions(+), 7 deletions(-) > > With this patch the error interrupt / stack dumps are no longer present. > > > > Thanks, > > > > Tested-by: Jeroen Hofstee > > Thanks, I'm suprised this was not caught earlier with all the automated > boot testing going on? At least speaking in terms the testbed results that I post, the warnings get reported. But not many people seem to act on them. (Jeroen is a pleasant exception.) See for example the "Build warnings from toolchain", "Kernel warnings during boot to userspace", "Kernel warnings during PM test", and "Obsolete Kconfig symbols" sections here: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/README.txt The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. - 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.1-rc6
Here are some basic OMAP test results for Linux v4.1-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150601012139/ 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-stk-om44, 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 (14/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 Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, 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 ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc5 (ba155e2d21f6bf05de86a78dbe5bfd8757604a65)): text data bsstotal kernel +5600 +56 omap1_defconfig +4800 +48 omap1_defconfig_1510innovator_only +4800 +48 omap1_defconfig_5912osk_only +26779 +2640 +27043 multi_v7_defconfig +107100+1071 omap2plus_defconfig +584 +640 +648 omap2plus_defconfig_2430sdp_only +107100+1071 omap2plus_defconfig_am33xx_only +107500+1075 omap2plus_defconfig_am43xx_only +107100+1071 omap2plus_defconfig_cpupm +107500+1075
Re: OMAP baseline test results for v4.1-rc5
+ Tero Hello Jeroen, On Mon, 1 Jun 2015, Jeroen Hofstee wrote: > On 30-05-15 17:56, Jeroen Hofstee wrote: > > Hello Paul, > > > > On 30-05-15 17:50, Paul Walmsley wrote: > > > Here are some basic OMAP test results for Linux v4.1-rc5. > > > Logs and other details at: > > > > > > http://www.pwsan.com/omap/testlogs/test_v4.1-rc5/20150529162206/ > > > > > > > The cmt3517 seems to have these some In-Band errors. > > Do you happen to know where these are coming from? > > > > git bisect + some workarounds seem to indicate: > > d744ce37b721d6678f420ba0fb058f615eb015b6 is the first bad commit > commit d744ce37b721d6678f420ba0fb058f615eb015b6 > Author: Tero Kristo > Date: Tue Feb 24 16:22:45 2015 +0200 > > ARM: dts: omap3: add minimal l4 bus layout with control module support > > This patch creates an l4_core interconnect for OMAP3, and moves some > of the generic peripherals under it. System control module nodes are > moved under this new interconnect also, and the SCM clock layout > is changed to use the renamed SCM node as the clock provider. > > Signed-off-by: Tero Kristo > Reported-by: Tony Lindgren > > I haven't looked further into it yet, Interesting; thanks for the bisect. In the mainline kernel, this appears to be commit b8845074cfbbd1d1b46720a1b563d7b4240dac21. I took a quick look at the control module offsets in that patch, and they appear to match what's in the SPRUGR0B PDF. Will try a few test boots here to confirm your findings. Tero, care to take a look? - 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: [PATCHv3 00/10] ARM: DRA7: add display support
Hi Tomi On Wed, 6 May 2015, Tomi Valkeinen wrote: > This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, > DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards > is added. > > This series is v3, and is based on v4.1-rc2. There are no differences to v2, > except rebased and tested. Are you still planning to move the DESHDCP clock enable to the beginning of the series to avoid the warnings, per: http://www.spinics.net/lists/arm-kernel/msg410968.html ? Also, not sure if you can arrange for someone at TI to send over a DRA7xx board for the testbed, but it would be nice to have a board to test these patches with, to avoid issues like the one mentioned in your E-mails... - 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.1-rc5
Here are some basic OMAP test results for Linux v4.1-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc5/20150529162206/ 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-stk-om44, 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 (14/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 Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 2/17): 5912osk, 3517evm Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, 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 ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.1-rc4 (e26081808edadfd257c6c9d81014e3b25e9a6118)): text data bsstotal kernel +165800+1658 omap1_defconfig +165800+1658 omap1_defconfig_1510innovator_only +165800+1658 omap1_defconfig_5912osk_only +28262 +529280 +81190 multi_v7_defconfig +267800+2678 omap2plus_defconfig +21300 -8+2122 omap2plus_defconfig_2430sdp_only +2550 +640+2614 omap2plus_defconfig_am33xx_only +255000+2550 omap2plus_defconfig_am43xx_only +267800+2678 omap2plus_defconfig_cpupm +261400+2614
Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock
On Wed, 20 May 2015, Stephen Boyd wrote: > On 05/20/15 04:50, Tero Kristo wrote: > > > >>> > >>> @@ -348,5 +348,10 @@ int __init dra7xx_dt_clk_init(void) > >>> if (rc) > >>> pr_err("%s: failed to set USB_DPLL M2 OUT\n", __func__); > >>> > >>> +hdcp_ck = clk_get_sys(NULL, "dss_deshdcp_clk"); > >>> +rc = clk_prepare_enable(hdcp_ck); > >>> +if (rc) > >>> +pr_err("%s: failed to set dss_deshdcp_clk\n", __func__); > >>> + > >>> return rc; > >>> } > >>> > >> > >> You should rather use the assigned-clock properties in DT to accomplish > >> this, the manual clock tweaks under the drivers/clk/ti/clk-* files > >> should be converted to DT setup also. > > > > Now that I sent this, I realize we only have support to set_parent / > > set_rate through the assigned-clock props, no enable. Any plans to > > extend this support Mike/Stephen? > > > > > > Enable falls under the "critical clocks" discussion that is ongoing. I > assume that this is some sort of critical clock that can't be turned off? It only needs to be enabled for this particular display IP subsystem to function: http://marc.info/?l=linux-omap&m=142071550111482&w=2 I believe Tomi is taking this approach (enabling it unconditionally) to avoid adding support for a secondary IP block "main clock" to the hwmod code. Apparently, the chips that contain this clock gating bit are not intended to be used for power-critical use cases, so there's not much motivation to switch it on and off with the display controller. - 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] memory: omap-gpmc: Add Kconfig option for debug
On Wed, 20 May 2015, Tony Lindgren wrote: > * Paul Walmsley [150520 15:52]: > > On Wed, 20 May 2015, Tony Lindgren wrote: > > > > > We support decoding the bootloader values if DEBUG is defined. > > > But we also need to change the struct omap_hwmod flags to have > > > HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the > > > boot. Otherwise just the default timings will be displayed > > > instead of the bootloader configured timings. > > > > > > This also allows us to clean up the various GPMC related > > > hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET, > > > and HWMOD_INIT_NO_IDLE is not needed. > > > > > > Cc: Brian Hutchinson > > > Cc: Paul Walmsley > > > Cc: Roger Quadros > > > Signed-off-by: Tony Lindgren > > > > Looks good to me, want me to queue it or do you want to? > > Feel free to take it if it looks OK to you, I'll just queue > the first patch then. Roger may have other GPMC patches > coming up, but this should not conflict with them, there's > more of a hwmod conflict chance. OK thanks queued for v4.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 2/2] memory: omap-gpmc: Add Kconfig option for debug
On Wed, 20 May 2015, Tony Lindgren wrote: > We support decoding the bootloader values if DEBUG is defined. > But we also need to change the struct omap_hwmod flags to have > HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the > boot. Otherwise just the default timings will be displayed > instead of the bootloader configured timings. > > This also allows us to clean up the various GPMC related > hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET, > and HWMOD_INIT_NO_IDLE is not needed. > > Cc: Brian Hutchinson > Cc: Paul Walmsley > Cc: Roger Quadros > Signed-off-by: Tony Lindgren Looks good to me, want me to queue it or do you want to? - 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: [PATCHv2 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
On Tue, 19 May 2015, Tero Kristo wrote: > Any news on this? As noted previously, I am not able to reproduce the issue > you are seeing currently, can you give DEBUG_LL a shot? Yeah I just bisected it, it was caused by this: commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e Author: Felipe Balbi Date: Fri Jan 30 11:18:56 2015 -0600 arm: config: omap2plus_defconfig: switch over to LZMA compression LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen Signed-off-by: Felipe Balbi Signed-off-by: Tony Lindgren and the timeouts on the testbed being set to fail if a kernel takes longer than five seconds to start. Seems that the part about a "slight extra decompression time" probably only applies to relatively recent chips. - 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: AM33xx+: hwmod: re-use omap4 implementations for reset functionality
On Tue, 5 May 2015, Tero Kristo wrote: > The reset code functionality is mostly a copy paste between OMAP4+ and > AM33xx+. Re-use the omap4 code where possible, and just keep the special > implementation for de-asserting the hardreset lines for AM33xx, as > AM33xx+ devices have slightly different register layouts compared to > OMAP4+. This patch also fixes the hardreset issues faced on AM43xx. > > Signed-off-by: Tero Kristo > Reported-by: Dave Gerlach > Reported-by: Anna Suman Thanks, queued for v4.1-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
OMAP baseline test results for v4.1-rc1
Here are some basic OMAP test results for Linux v4.1-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.1-rc1/20150426200156/ 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 (14/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 Boot to userspace: FAIL ( 6/17): 4460varsomom, 2430sdp, 3530es3beagle, 3530es31beagle, cmt3517, 5430es2sbct54 skip ( 2/17): 5912osk, 3517evm Pass ( 9/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 37xxevm, 3730beaglexm, 3730es12beaglexm, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 1/17): 4430es2panda PM: chip retention via suspend: FAIL ( 8/12): am335xbonelt, 4430es2panda, 4460varsomom, 3530es3beagle, 3530es31beagle, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 4/12): 4460pandaes, 37xxevm, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 9/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 3530es3beagle, 3530es31beagle, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 3/12): 37xxevm, 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: FAIL ( 2/ 4): 3530es3beagle, 3530es31beagle Pass ( 2/ 4): 37xxevm, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 2/ 4): 3530es3beagle, 3530es31beagle Pass ( 2/ 4): 37xxevm, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 1/20): multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0 (39a8804455fb23f09157341d3ba7db6d7ae6ee76)): text data bsstotal kernel +39378 +632 +760 +40770 omap1_defconfig +41722 +616 +760 +43098 omap1_defconfig_1510innovator_only +40430 +592 +728 +41750 omap1_defconfig_5912osk_only +329506 +29440+1472 +360418 multi_v7_defconfig +230849 +164752+1664 +397265 omap2plus_defconfig +203731 +159872+1520 +365123 omap2plus_defconfig_2430sdp_only +234533 +172200+1664 +408397 omap2plus_defconfig_am33xx_only +235213 +172832+1664 +409709 omap2plus_defconfig_am43xx_only +235137 +164808+1728 +401673 omap2plus_defconfig_cpupm +235341 +173200+1728 +410269 omap2plus_defconfig_
OMAP baseline test results for v4.0
Here are some basic OMAP test results for Linux v4.0. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0/20150421081056/ 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 ( 7/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 5/12): 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 ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc7 (f22e6e847115abc3a0e2ad7bb18d243d42275af1)): text data bsstotal kernel +148 -80 +140 omap1_defconfig +14800 +148 omap1_defconfig_1510innovator_only +18000 +180 omap1_defconfig_5912osk_only -48-15200-1568 multi_v7_defconfig +9600 +96 omap2plus_defconfig +9200 +92 omap2plus_defconfig_2430sdp_only +9600 +96 omap2plus_defconfig_am33xx_only +96 +80 +104 omap2plus_defconfig_am43xx_only +96 +80 +104 omap2plus_
OMAP baseline test results for v4.0-rc7
Here are some basic OMAP test results for Linux v4.0-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc7/20150421071440/ 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 ( 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 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-rc6 (e42391cd048809d903291d07f86ed3934ce138e9)): text data bsstotal kernel +1079 +1200+1199 omap1_defconfig +1079 +720+1151 omap1_defconfig_1510innovator_only +1079 +800+1159 omap1_defconfig_5912osk_only +915 +720 +987 multi_v7_defconfig +743 +1760 +919 omap2plus_defconfig +4743 +1680+4911 omap2plus_defconfig_2430sdp_only +679 +1360 +815 omap2plus_defconfig_am33xx_only +679 +2000 +879 omap2plus_defconfig_am43xx_only +743 +1680 +911 om
Re: [PATCH v3] ARM: AM43xx: hwmod: add VPFE hwmod entries
On Fri, 10 Apr 2015, Lad, Prabhakar wrote: > On Fri, Apr 10, 2015 at 11:51 PM, Paul Walmsley wrote: > > Hi Prabhakar > > > > On Fri, 10 Apr 2015, Lad, Prabhakar wrote: > > > >> Hi Paul, > >> > >> On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley wrote: > >> > On Wed, 28 Jan 2015, Benoit Parrot wrote: > >> > > >> >> Suspend/resume is functional with this patch. > >> >> > >> >> Tested-by: Benoit Parrot > >> > > >> > Thanks folks, queued for v3.21. > >> > > >> > > >> I see that this patch is not into linux-next yet. > > > > thanks for the ping. This slipped through the cracks here due to the > > kernel version number change from 3.21 to 4.1 :-( Sorry about that; I > > will requeue for either 4.1-rc or 4.2. > > > > Unfortunately I don't have an AM43xx board. Is suspend/resume broken > > without this patch? If so, then v4.1-rc seems like the appropriate > > target. > > > there is kernel soft crashes without this patch, so this needs to go > in for v4.1-rc. Could you provide some further detail? Does it crash during boot, or during suspend, or ... ? Also could you describe what you mean by "soft crash" ? - 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
Hi Prabhakar On Fri, 10 Apr 2015, Lad, Prabhakar wrote: > Hi Paul, > > On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley wrote: > > On Wed, 28 Jan 2015, Benoit Parrot wrote: > > > >> Suspend/resume is functional with this patch. > >> > >> Tested-by: Benoit Parrot > > > > Thanks folks, queued for v3.21. > > > > > I see that this patch is not into linux-next yet. thanks for the ping. This slipped through the cracks here due to the kernel version number change from 3.21 to 4.1 :-( Sorry about that; I will requeue for either 4.1-rc or 4.2. Unfortunately I don't have an AM43xx board. Is suspend/resume broken without this patch? If so, then v4.1-rc seems like the appropriate target. - 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+: OMAP DRA7xx display-related hwmod data changes for v4.1
On Tue, 7 Apr 2015, Tomi Valkeinen wrote: > Hi, > > No, don't pull this, it doesn't work. > > Paul, the hwmod patch cannot be picked from the DRA7 DSS series. We have > the problem with the DES HDCP clock, without that clock we will see > WARNINGs when booting if the "set DSS submodule parent hwmods" is applied. > > We do see some errors when booting even with the current mainline, > caused by not having that clock enabled: > > [0.194524] omap_hwmod: dss_core: _wait_target_disable failed > [0.194540] omap_hwmod: dss_core: _wait_target_ready failed: -16 > [0.194554] omap_hwmod: dss_core: cannot be enabled for reset (3) > [0.197143] omap_hwmod: dss_dispc: _wait_target_ready failed: -16 > [0.197156] omap_hwmod: dss_dispc: cannot be enabled for reset (3) > [0.199745] omap_hwmod: dss_hdmi: _wait_target_ready failed: -16 > [0.199759] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > > But that's still much less spam than the above plus ~4 WARNs. > > I'd rather merge the DRA7 DSS patches in one go, to avoid issues related > to the HDPC clock. OK, sorry for the misunderstanding. - 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+: OMAP DRA7xx display-related hwmod data changes for v4.1
-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.1/omap-hwmod-b for you to fetch changes up to 0d75ebdd3230b3d085812df80ec54138828cc76a: ARM: DRA7: hwmod: set DSS submodule parent hwmods (2015-04-03 13:15:07 -0600) - OMAP DRA7xx display-related hwmod data changes for v4.1 Add DMM hwmod data for DRA7xx, and set the parent hwmods fields appropriately for the DRA7xx DSS submodules as we've done for other OMAP devices. Note that I do not have a DRA7xx board, and thus cannot boot-test these patches. Basic build, boot, and PM idle test logs are available at: http://www.pwsan.com/omap/testlogs/omap-hwmod-b-for-v4.1/20150403123702/ - Tomi Valkeinen (2): ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32 +++ 1 file changed, 32 insertions(+) vmlinux object size (delta in bytes from test_v4.0-rc1 (c517d838eb7d07bbe9507871fab3931deccff539)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only 0 +1920 +192 multi_v7_defconfig 0 +2160 +216 omap2plus_defconfig 0000 omap2plus_defconfig_2430sdp_only 0000 omap2plus_defconfig_am33xx_only 0000 omap2plus_defconfig_am43xx_only 0 +2240 +224 omap2plus_defconfig_cpupm 0 +1920 +192 omap2plus_defconfig_dra7xx_only 0000 omap2plus_defconfig_n800_multi_omap2xxx 0000 omap2plus_defconfig_n800_only_a 0 +1920 +192 omap2plus_defconfig_no_pm 0000 omap2plus_defconfig_omap2_4_only 0000 omap2plus_defconfig_omap3_4_only 0000 omap2plus_defconfig_omap5_only 0000 rmk_omap3430_ldp_allnoconfig 0000 rmk_omap3430_ldp_oldconfig +80 -80 rmk_omap4430_sdp_allnoconfig 0000 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v4.0-rc1 (c517d838eb7d07bbe9507871fab3931deccff539)) avail rsrvd high freed board kconfig -4k 4k . . 4460pandaesomap2plus_defconfig -12k12k . . 4460varsomom omap2plus_defconfig -4k 4k . . 5430es2sbct54 omap2plus_defconfig -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVHu+NAAoJEMePsQ0LvSpLdvcP/A2Vh1CtCdVWA95K+QovF4uG aC+ZSMXkjrr7Widr28wtfjMYvO3N6UW5uzoPcbgrWQOEMNa/9qMYXRWd/KIL8nOP Hoy2NZy2y5p3j+GRsnSTftSuyXcpvSUvvSRUFxR/o0LNwo+HuNjNJ+tuenFDqZUy LIp8AUn+4bu0WlXVJsq1aDOZdI+nvmHifvMEIjAXQM38QaXdP8xDDdaaPiNPnznT a9TsOPzSrkXfrS4q+QtaVtWoc6LlAtPTqO9Ss+xRpxTU/67DLIf6zQBnBuH6ZwHL vV3J97IC97CIg7KYzYrGfT3KjBx307R7Yo0pK6lVbRgJVG9ZweJEnZa332+tlJ1z neiZ5pS4JZv4tXpB3TpTSe1QRUBMyNCecvSVsJQ4zL1IiFYsqI360selASPaQCrI xKZZOVBl3H23MxDtob7AfS2sv34m9aqGuT7KNMPjBlwkRuAyx6kE1ZmZNSyMgtts wJmTkklx15HV4BrnT18Y4w8CmTQCVEzQFRDqGoVPCL/UVK/0VefxAvDmjFNwMVck JjXN9TAfbOp6zXwS/AwhdjtSZEHOSETeKbh2rOEp90mWV0kYgFTZf303AmAsIu+S TwKeMrT3Zby+2WNzMu8kV/RjHRbxamO2GE8exWZCnZqwn8wqIw0Y8McelFyBre8F A4Niw8T1XPDR6XYY3tij =Tutb -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: [PATCHv2 03/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods
On Tue, 24 Mar 2015, Tomi Valkeinen wrote: > Set DSS core hwmod as the parent for all the DSS submodules. > > Signed-off-by: Tomi Valkeinen Thanks, queued. Will send a pull request for this to Tony today, but it may not make it for v4.1. Note that I cannot boot test this since I do not 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
Re: [PATCHv2 02/10] ARM: DRA7: hwmod: add DMM hwmod description
On Tue, 24 Mar 2015, Tomi Valkeinen wrote: > Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5. > > Signed-off-by: Tomi Valkeinen Thanks, queued. Will send a pull request for this to Tony today, but it may not make it for v4.1. Note that I cannot boot-test this since I do not have a DRA7 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 v4.0-rc6
Here are some basic OMAP test results for Linux v4.0-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc6/20150401180311/ 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-rc5 (bc465aa9d045feb0e13b4a8f32cc33c1943f62d6)): text data bsstotal kernel +56100 +561 omap1_defconfig +40100 +401 omap1_defconfig_1510innovator_only +49700 +497 omap1_defconfig_5912osk_only +264 -160 +248 multi_v7_defconfig +2189 +880+2277 omap2plus_defconfig +197300+1973 omap2plus_defconfig_2430sdp_only +2141 +720+2213 omap2plus_defconfig_am33xx_only +2145 +640+2209 omap2plus_defconfig_am43xx_only +2189 +800+2269 om
[GIT PULL] ARM: OMAP2+: hwmod data changes for AM43xx and DRA7xx for v4.1
-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.1/omap-hwmod-a for you to fetch changes up to edec17863362e0106b9e6b2f83237c7bd535e346: ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4 (2015-03-24 11:52:50 -0600) - OMAP hwmod data changes for AM43xx and DRA7xx for v4.1 Add support for the AM43xx HDQ/1-wire driver and fix the GPTIMER data for DRA7xx. Note that I do not have AM43xx nor DRA7xx boards, and cannot test these patches on those platforms. Basic build, boot, and PM test logs are available at: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v4.1/20150324185246/ - Sourav Poddar (1): ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W Suman Anna (2): ARM: DRA7: hwmod: Add data for GPTimers 13 through 16 ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 113 + arch/arm/mach-omap2/prcm43xx.h | 1 + 3 files changed, 134 insertions(+), 16 deletions(-) vmlinux object size (delta in bytes from test_v4.0-rc1 (c517d838eb7d07bbe9507871fab3931deccff539)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only 0 +8000 +800 multi_v7_defconfig 0 +9200 +920 omap2plus_defconfig 0000 omap2plus_defconfig_2430sdp_only 0000 omap2plus_defconfig_am33xx_only 0 +2560 +256 omap2plus_defconfig_am43xx_only 0 +9280 +928 omap2plus_defconfig_cpupm 0 +7040 +704 omap2plus_defconfig_dra7xx_only 0000 omap2plus_defconfig_n800_multi_omap2xxx 0000 omap2plus_defconfig_n800_only_a 0 +8960 +896 omap2plus_defconfig_no_pm 0000 omap2plus_defconfig_omap2_4_only 0000 omap2plus_defconfig_omap3_4_only 0000 omap2plus_defconfig_omap5_only 0000 rmk_omap3430_ldp_allnoconfig 0000 rmk_omap3430_ldp_oldconfig 0000 rmk_omap4430_sdp_allnoconfig 0000 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v4.0-rc1 (c517d838eb7d07bbe9507871fab3931deccff539)) avail rsrvd high freed board kconfig -117772k -13300k . -168k 2420n800 omap2plus_defconfig_n800_only_a -4k 4k . . 37xxevmomap2plus_defconfig -4k 4k . . 4430es2panda omap2plus_defconfig -4k 4k . . 4460pandaesomap2plus_defconfig -4k 4k . . 5430es2sbct54 omap2plus_defconfig -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVFSvrAAoJEMePsQ0LvSpLYkAP/RLWARugTgWyy5qolLMVxkNC Zk+vILZNF0D7MkYPAg8HY1XXYajkGrAsuUreboVRs8yCXhkEEQDAbXNV1/kUXYcS KUO9fnqDtYS9hl2Z0lX2XrhonuroyuEm2OBZgbJFaDPJ/H/AVMvip+QbVDlb3Vkl Op/ckOhAmVNUKtMN5AYhhrvr2zIVa6+AjFVanfqFgDyfIBzyHeK5G/6ZYiQX1aW4 psAQDwRaK+j6Og1899j3Xk8AflMng2u77L2Mv3QrkcByNxvEt9Sq1HqNYYUs0Rrl S+j63ypEDs3LiDh2vfxK3KaC9AtQaLcCkOfQ0/rpwJ/1MYr4xB/UqGcCv6Qyx19i e4g2Eux9CUoJdPAyOKKtpDitMxEOsVEQobfbfzahNNbFGl5g29qc7rJkNO9EfIdt YqZh4202jC52c1ax+CYCjv/hOakZZdWydf0U88ZdM/LZbS9XRFDnRLYCyCK7qKnc aZe/6NxMwvcOOnQvt79UUZJdMfthYWUY/SlXzKE5M39/0YnbUclkoLYN/Xb/S5Yw W3ZGJWEVzhMjoW+8AyX+PfviWvp/Zgj9ADpidCln5qYTdlGeOvi2dYKN8edbeShk kdgnsc1htNDzV1hJWaWKpJC2AQzg1Nx4hGvfVreitCPcqpY2i+AOfIiuJ8pWU5mT dryy4IFJRPyxXYmPN8gb =CIxb -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 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 26 Mar 2015, Kishon Vijay Abraham I wrote: > On Thursday 19 March 2015 10:19 PM, Paul Walmsley wrote: > > 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 [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. > > huh.. was under the assumption that patches for device tree and the kernel > patches should be separate. Generally that's true, _unless_ separating them will break something between the two patches. That appears to be the case here. The important thing is to make sure every single commit builds and functions at least as well as the previous commit - i.e., there should be no regressions. - 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