Message ID | alpine.DEB.2.00.1209210103140.6888@utopia.booyaka.com |
---|---|
State | New |
Headers | show |
* Paul Walmsley <paul@pwsan.com> [120920 18:05]: > Hi Tony > > The following changes since commit c4dbc7c086ce96d17f18b7a4a965b01d54d45f46: > > Merge tag 'cleanup-fixes-for-v3.7' into test_merge_v3.6-rc6_cleanup-fixes (2012-09-19 13:54:08 -0600) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.7 Thanks pulling into devel-late. Note that we're pretty much out of time for v3.7 merge window, so most likely this won't get merged until for v3.8. See message "Status of arm-soc for 3.7" posted to LAKML for details. Regards, Tony > for you to fetch changes up to 2d8abe08923834bc41fb4d811b437033f567531e: > > ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 (2012-09-20 18:23:39 -0600) > > ---------------------------------------------------------------- > Behind this tag are OMAP patches intended for the 3.7 merge window, for: > > - Runtime PM conversions for the GPMC and RNG IP blocks > - Performance Monitoring Unit (PMU) support for OMAP2, 3, and non-4430 OMAP4 > - OMAP hwmod code and data improvements > - Preparation patches for the IOMMU runtime PM conversion > - Preparation patches for OMAP4 full-chip retention support > > Based on a merge of v3.6-rc6 and the cleanup-fixes-for-v3.7 > tag (de6ca33a96a6bf61fcb91d3d399703e19ead9d1e), due to > dependencies. > > These patches have been tested for meaningful warnings from > checkpatch, sparse, smatch, and cppcheck. Basic build, boot[1], and > PM test logs are available here: > > http://www.pwsan.com/omap/testlogs/omap_hwmod_prcm_devel_a_3.7/20120920182344/ > > ... > > 1. Note that the N800 boot fails due to a known issue present in the > base commit: > > http://www.spinics.net/lists/arm-kernel/msg196034.html > > ---------------------------------------------------------------- > > object size (delta in bytes from test_merge_v3.6-rc6_cleanup-fixes (c4dbc7c086ce96d17f18b7a4a965b01d54d45f46)): > text data bss total kernel > +1428 +256 0 +1684 2430_testconfig > +180 +432 0 +612 5912osk_testconfig > +1152 +1736 0 +2888 am33xx_testconfig > +1304 +280 -8 +1576 n800_b_testconfig > +1336 +352 +56 +1744 n800_multi_omap2xxx > +1288 +256 -8 +1536 n800_testconfig > 0 0 0 0 omap1510_defconfig > +184 +448 0 +632 omap1_defconfig > +5564 +1392 -8 +6948 omap2_4_testconfig > +1104 +2608 0 +3712 omap2plus_defconfig > +1100 +2584 0 +3684 omap2plus_defconfig_cpupm > +5104 +2592 0 +7696 omap2plus_no_pm > +1424 +1840 0 +3264 omap3_4_testconfig > +1036 +864 +64 +1964 omap3_testconfig > +5592 +1088 0 +6680 omap4_testconfig > +1096 +800 0 +1896 rmk_omap3430_ldp_oldconfig > +1344 +968 0 +2312 rmk_omap4430_sdp_oldconfig > > > Afzal Mohammed (3): > ARM: OMAP2/3: hwmod data: add gpmc > ARM: OMAP2+: gpmc: Adapt to HWMOD > ARM: OMAP2+: gpmc: minimal driver support > > Benoit Cousson (1): > ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries > > Igor Grinberg (1): > ARM: OMAP: hwmod code: remove unused hwmod function prototypes > > Jon Hunter (5): > ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP > ARM: OMAP3: hwmod data: Add debugss HWMOD data > ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD > ARM: OMAP2+: PMU: Add runtime PM support > ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70 > > Kishon Vijay Abraham I (1): > ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp > > Ming Lei (1): > ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD > > Omar Ramirez Luna (5): > ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices > ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled > ARM: OMAP: hwmod: revise deassert sequence > ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected > ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp > > Paul Walmsley (10): > ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*() > ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages > ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocks > ARM: OMAP3: hwmod data: add mmu data for iva and isp > ARM: OMAP2xxx: hwmod/CM: add RNG integration data > hwrng: OMAP: store per-device data in per-device variables, not file statics > hwrng: OMAP: convert to use runtime PM > ARM: OMAP: split OMAP1, OMAP2+ RNG device registration > hwrng: OMAP: remove SoC restrictions from driver registration > ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems > > Tero Kristo (4): > ARM: OMAP4: powerdomain: add support for reading prev logic and mem states > ARM: OMAP4: hwmod data: add support for lostcontext_mask > ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status > ARM: OMAP3: hwmod data: add sad2d hwmod > > arch/arm/mach-omap1/devices.c | 28 ++ > arch/arm/mach-omap1/timer.c | 2 +- > arch/arm/mach-omap2/Makefile | 1 + > arch/arm/mach-omap2/clockdomain.c | 17 ++ > arch/arm/mach-omap2/clockdomain.h | 20 +- > arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 22 ++ > arch/arm/mach-omap2/clockdomain44xx.c | 11 + > arch/arm/mach-omap2/clockdomains3xxx_data.c | 7 +- > arch/arm/mach-omap2/clockdomains44xx_data.c | 3 +- > arch/arm/mach-omap2/cm-regbits-34xx.h | 2 + > arch/arm/mach-omap2/cm2xxx_3xxx.c | 2 +- > arch/arm/mach-omap2/cm2xxx_3xxx.h | 1 + > arch/arm/mach-omap2/devices.c | 39 +-- > arch/arm/mach-omap2/gpmc.c | 194 ++++++++++---- > arch/arm/mach-omap2/omap_hwmod.c | 93 +++++-- > arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 ++ > arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 ++ > .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 17 ++ > arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 110 +++++++- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 +++++++++++++++++++- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 243 ++++++++++++++++- > arch/arm/mach-omap2/omap_hwmod_common_data.h | 6 +- > arch/arm/mach-omap2/pm.c | 3 +- > arch/arm/mach-omap2/pmu.c | 95 +++++++ > arch/arm/mach-omap2/powerdomain44xx.c | 61 ++++- > arch/arm/mach-omap2/prcm-common.h | 2 + > arch/arm/plat-omap/include/plat/dmtimer.h | 1 + > arch/arm/plat-omap/include/plat/iommu.h | 15 ++ > arch/arm/plat-omap/include/plat/omap_device.h | 4 + > arch/arm/plat-omap/include/plat/omap_hwmod.h | 26 +- > arch/arm/plat-omap/omap_device.c | 55 ++++ > drivers/char/hw_random/omap-rng.c | 121 +++++---- > 32 files changed, 1336 insertions(+), 183 deletions(-) > create mode 100644 arch/arm/mach-omap2/pmu.c
* Tony Lindgren <tony@atomide.com> [120921 13:55]: > * Paul Walmsley <paul@pwsan.com> [120920 18:05]: > > Hi Tony > > > > The following changes since commit c4dbc7c086ce96d17f18b7a4a965b01d54d45f46: > > > > Merge tag 'cleanup-fixes-for-v3.7' into test_merge_v3.6-rc6_cleanup-fixes (2012-09-19 13:54:08 -0600) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-b-for-3.7 > > Thanks pulling into devel-late. > > Note that we're pretty much out of time for v3.7 merge window, so > most likely this won't get merged until for v3.8. See message > "Status of arm-soc for 3.7" posted to LAKML for details. I tried merging this into tmp-merge, but ran into all kinds of merge conflicts with the am33xx code etc and ended up with a result that booted with all kinds of warnings on 2430sdp and did not boot at all on zoom3 :) So I probably did something wrong.. Care to base this on something more mergeable? Maybe a merge of cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7? Ideally it would be based on something that merges nicely when pulled into arm-soc/for-next, but that might be a bit hard to do right now. Regards, Tony
On Fri, 21 Sep 2012, Tony Lindgren wrote: > I tried merging this into tmp-merge, but ran into all kinds of > merge conflicts with the am33xx code etc and ended up with a > result that booted with all kinds of warnings on 2430sdp and > did not boot at all on zoom3 :) So I probably did something > wrong.. > > Care to base this on something more mergeable? Just let me know what you want me to base it on. > Maybe a merge of cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7? The series rebases cleanly onto cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7, so I guess you'll probably want me to base it somewhere else? - Paul
* Paul Walmsley <paul@pwsan.com> [120921 17:04]: > On Fri, 21 Sep 2012, Tony Lindgren wrote: > > > I tried merging this into tmp-merge, but ran into all kinds of > > merge conflicts with the am33xx code etc and ended up with a > > result that booted with all kinds of warnings on 2430sdp and > > did not boot at all on zoom3 :) So I probably did something > > wrong.. > > > > Care to base this on something more mergeable? > > Just let me know what you want me to base it on. > > > Maybe a merge of cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7? > > The series rebases cleanly onto cleanup-fixes-for-v3.7 + > omap-devel-am33xx-for-v3.7, so I guess you'll probably want me to base it > somewhere else? Hmm I wonder what's causing it then? There must be something else in tmp-merge at commit abfee61f that causes the problems. Maybe try to merge with that commit and see what you get? That commit can't be used as a base though as that's temporary most likely.. But we can create a base to use out of the branches once we know them, you can do it yourself too. Regards, Tony
On Fri, 21 Sep 2012, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [120921 13:55]: > > Care to base this on something more mergeable? Maybe a merge > of cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7? While working on this, noticed that the 4430ES2 Panda test boot failed on the merge base of cleanup-fixes-for-v3.7 and omap-devel-am33xx-for-v3.7. Enabling DEBUG_LL and adding some debug revealed that the static variable 'arch_clkdm' in mach-omap2/clockdomain.c was getting overwritten between omap44xx_clockdomains_init() and the end of IRQ setup. This was bisected down to this commit: commit ec2c0825ca3183a646a24717966cc7752e8b0393 Author: Tony Lindgren <tony@atomide.com> Date: Mon Aug 27 17:43:01 2012 -0700 ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ Remove hardcoded IRQs in irqs.h and related files as these are no longer needed. ... Looks to me like something is wrong with the IRQ allocation and it's corrupting memory. - Paul [ In the following dump, the lines beginning with 'a:' are logged at the beginning of _clkdm_clk_hwmod_enable(). The number on the right represents whether arch_clkdm is nonzero (1) or zero (0) ] ... [ 0.000000] free_area_init_node: node 0, pgdat c07af500, node_mem_map c0d0d000 [ 0.000000] Normal zone: 1024 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 125696 pages, LIFO batch:31 [ 0.000000] OMAP4430 ES2.0 [ 0.000000] a: l3_instr_clkdm 1 [ 0.000000] a: l3_instr_clkdm 1 [ 0.000000] a: l3_instr_clkdm 1 [ 0.000000] a: l3_2_clkdm 1 [ 0.000000] a: l3_emif_clkdm 1 [ 0.000000] a: l3_emif_clkdm 1 [ 0.000000] a: l3_emif_clkdm 1 [ 0.000000] PERCPU: Embedded 9 pages/cpu @c1115000 s12736 r8192 d15936 u36864 [ 0.000000] pcpu-alloc: s12736 r8192 d15936 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125696 [ 0.000000] Kernel command line: console=ttyO2,230400n8 vram=16M root=/dev/mmcblk0p2 rw rootfstype=ext3\ rootwait earlyprintk debug ignore_loglevel [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 495MB = 495MB total [ 0.000000] Memory: 488916k/488916k available, 35372k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB) [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc06d6b18 (6971 kB) [ 0.000000] .init : 0xc06d7000 - 0xc07261c0 ( 317 kB) [ 0.000000] .data : 0xc0728000 - 0xc07b1d00 ( 552 kB) [ 0.000000] .bss : 0xc07b1d24 - 0xc0d0c34c (5482 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [ 0.000000] a: mpuss_clkdm 0 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1941 _enable+0x1bc/0x204() [ 0.000000] omap_hwmod: mpu: could not enable clockdomain mpuss_clkdm: -22 [ 0.000000] Modules linked in: [ 0.000000] [<c001b94c>] (unwind_backtrace+0x0/0xf0) from [<c004239c>] (warn_slowpath_common+0x4c/0x64) [ 0.000000] [<c004239c>] (warn_slowpath_common+0x4c/0x64) from [<c0042448>] (warn_slowpath_fmt+0x30/0x4\ 0) [ 0.000000] [<c0042448>] (warn_slowpath_fmt+0x30/0x40) from [<c00292e8>] (_enable+0x1bc/0x204) [ 0.000000] [<c00292e8>] (_enable+0x1bc/0x204) from [<c06e2bf8>] (_setup+0x78/0x150) [ 0.000000] [<c06e2bf8>] (_setup+0x78/0x150) from [<c06e3204>] (omap_hwmod_setup_one+0x4c/0x60) [ 0.000000] [<c06e3204>] (omap_hwmod_setup_one+0x4c/0x60) from [<c06e31ec>] (omap_hwmod_setup_one+0x34/\ 0x60) [ 0.000000] [<c06e31ec>] (omap_hwmod_setup_one+0x34/0x60) from [<c06e1340>] (omap_dm_timer_init_one+0x2\ c/0x234) [ 0.000000] [<c06e1340>] (omap_dm_timer_init_one+0x2c/0x234) from [<c06e1564>] (omap2_gp_clockevent_ini\ t+0x1c/0x114) [ 0.000000] [<c06e1564>] (omap2_gp_clockevent_init+0x1c/0x114) from [<c06e1808>] (omap4_timer_init+0x10\ /0x58) [ 0.000000] [<c06e1808>] (omap4_timer_init+0x10/0x58) from [<c06db3a0>] (time_init+0x20/0x30) [ 0.000000] [<c06db3a0>] (time_init+0x20/0x30) from [<c06d76b0>] (start_kernel+0x1b4/0x304) [ 0.000000] [<c06d76b0>] (start_kernel+0x1b4/0x304) from [<80008044>] (0x80008044) [ 0.000000] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.000000] omap_hwmod: mpu: cannot be enabled for reset (3)
* Paul Walmsley <paul@pwsan.com> [120921 22:41]: > > On Fri, 21 Sep 2012, Tony Lindgren wrote: > > > * Tony Lindgren <tony@atomide.com> [120921 13:55]: > > > > Care to base this on something more mergeable? Maybe a merge > > of cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7? > > While working on this, noticed that the 4430ES2 Panda test boot failed on > the merge base of cleanup-fixes-for-v3.7 and omap-devel-am33xx-for-v3.7. > Enabling DEBUG_LL and adding some debug revealed that the static variable > 'arch_clkdm' in mach-omap2/clockdomain.c was getting overwritten between > omap44xx_clockdomains_init() and the end of IRQ setup. This was bisected > down to this commit: > > commit ec2c0825ca3183a646a24717966cc7752e8b0393 > Author: Tony Lindgren <tony@atomide.com> > Date: Mon Aug 27 17:43:01 2012 -0700 > > ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ > > Remove hardcoded IRQs in irqs.h and related files as these > are no longer needed. > > ... > > Looks to me like something is wrong with the IRQ allocation and it's > corrupting memory. Yeah I bet that's e534e871 (ARM: OMAP4: Fix array size for irq_target_cpu) already in mainline since -rc6. Regards, Tony
On Fri, 21 Sep 2012, Tony Lindgren wrote: > Hmm I wonder what's causing it then? There must be something > else in tmp-merge at commit abfee61f that causes the problems. > Maybe try to merge with that commit and see what you get? Probably the merge with the clock patches was causing trouble. > That commit can't be used as a base though as that's temporary > most likely.. But we can create a base to use out of the > branches once we know them, you can do it yourself too. Your tmp-merge contains branch/tag merges that haven't yet gone upstream to arm-soc. I don't know which of those merges you consider stable (aside from the upstream ones, obviously). For this one it looks like the clock patches were the ones causing the merge trouble. So since that series also came from me and is unmerged, will just merge the clock and hwmod patches into a new pull request on v3.6-rc6 + cleanup-fixes-for-v3.7 + omap-devel-am33xx-for-v3.7. Hopefully that will work for you... - Paul
* Paul Walmsley <paul@pwsan.com> [120922 10:48]: > On Fri, 21 Sep 2012, Tony Lindgren wrote: > > > Hmm I wonder what's causing it then? There must be something > > else in tmp-merge at commit abfee61f that causes the problems. > > Maybe try to merge with that commit and see what you get? > > Probably the merge with the clock patches was causing trouble. > > > That commit can't be used as a base though as that's temporary > > most likely.. But we can create a base to use out of the > > branches once we know them, you can do it yourself too. > > Your tmp-merge contains branch/tag merges that haven't yet gone upstream > to arm-soc. I don't know which of those merges you consider stable (aside > from the upstream ones, obviously). For this one it looks like the clock > patches were the ones causing the merge trouble. So since that series > also came from me and is unmerged, will just merge the clock and hwmod > patches into a new pull request on v3.6-rc6 + cleanup-fixes-for-v3.7 + > omap-devel-am33xx-for-v3.7. Hopefully that will work for you... Well tmp-merge is a merge of the upstream branches, but the branch itself is temporary. The issue here is that's it's too messy to get your branch merged currently because of the various merge conflicts with other branches. Trying to merge in your updated branch for testing into tmp-merge with the other branches produces: CONFLICT (content): Merge conflict in drivers/spi/spi-omap2-mcspi.c CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap_hwmod.c CONFLICT (content): Merge conflict in arch/arm/mach-omap2/gpmc.c CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_dpll.c CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_clksel.c CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt34xx_dpll3m2.c It seems to be conflicting with your own formatting changes, am33xx changes, PMU changes and RNG changes. Sounds like we're safest to wait for -rc1 to for the dependencies to clear? Regards, Tony
* Tony Lindgren <tony@atomide.com> [120923 12:11]: > * Paul Walmsley <paul@pwsan.com> [120922 10:48]: > > On Fri, 21 Sep 2012, Tony Lindgren wrote: > > > > > Hmm I wonder what's causing it then? There must be something > > > else in tmp-merge at commit abfee61f that causes the problems. > > > Maybe try to merge with that commit and see what you get? > > > > Probably the merge with the clock patches was causing trouble. > > > > > That commit can't be used as a base though as that's temporary > > > most likely.. But we can create a base to use out of the > > > branches once we know them, you can do it yourself too. > > > > Your tmp-merge contains branch/tag merges that haven't yet gone upstream > > to arm-soc. I don't know which of those merges you consider stable (aside > > from the upstream ones, obviously). For this one it looks like the clock > > patches were the ones causing the merge trouble. So since that series > > also came from me and is unmerged, will just merge the clock and hwmod > > patches into a new pull request on v3.6-rc6 + cleanup-fixes-for-v3.7 + > > omap-devel-am33xx-for-v3.7. Hopefully that will work for you... > > Well tmp-merge is a merge of the upstream branches, but the branch > itself is temporary. The issue here is that's it's too messy to get > your branch merged currently because of the various merge conflicts with > other branches. Trying to merge in your updated branch for testing > into tmp-merge with the other branches produces: > > CONFLICT (content): Merge conflict in drivers/spi/spi-omap2-mcspi.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap_hwmod.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/gpmc.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_dpll.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_clksel.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt34xx_dpll3m2.c > > It seems to be conflicting with your own formatting changes, > am33xx changes, PMU changes and RNG changes. Sounds like we're > safest to wait for -rc1 to for the dependencies to clear? Or maybe it's possible to split the series into smaller chunks that can be pulled in to the existing branches without causing new merge conflicts? > Regards, > > Tony
On Sun, 23 Sep 2012, Tony Lindgren wrote: > * Paul Walmsley <paul@pwsan.com> [120922 10:48]: > > > Your tmp-merge contains branch/tag merges that haven't yet gone upstream > > to arm-soc. I don't know which of those merges you consider stable (aside > > from the upstream ones, obviously). > > Well tmp-merge is a merge of the upstream branches, but the branch > itself is temporary. tmp-merge at commit abfee61f contains some branches/tags that aren't upstream at arm-soc - for example, Santosh's omap5_arch_timer (3c7c5da) and my omap-devel-c-for-3.7 (a238ce7). > The issue here is that's it's too messy to get > your branch merged currently because of the various merge conflicts with > other branches. Trying to merge in your updated branch for testing > into tmp-merge with the other branches produces: > > CONFLICT (content): Merge conflict in drivers/spi/spi-omap2-mcspi.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap_hwmod.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/gpmc.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_dpll.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_clksel.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt34xx_dpll3m2.c If you don't want to resolve the conflicts yourself, I'll be happy to do it if you give me a stable commit for me to base my pull request on. But probably those conflicts are due to a miscommunication; see below. > It seems to be conflicting with your own formatting changes, > am33xx changes, PMU changes and RNG changes. The PMU changes and RNG changes are in the tag you're pulling. There aren't any previous changes in those areas from me. Did you drop the temporary merge of omap-devel-c-for-3.7 before pulling omap-devel-b-c-for-3.7? I merged the b (hwmod/etc.) and c (clock) pull requests into the updated pull request to reduce merge conflicts for you. - Paul
* Paul Walmsley <paul@pwsan.com> [120923 18:09]: > On Sun, 23 Sep 2012, Tony Lindgren wrote: > > > Or maybe it's possible to split the series into smaller chunks > > that can be pulled in to the existing branches without causing > > new merge conflicts? > > Well here's what I did, hopefully it's suitable. Built a tag with all of > the clock and hwmod/runtime PM patches together, and based it on v3.6-rc6 > + omap-cleanup-b-for-3.7 + cleanup-fixes-for-v3.7 + > omap-devel-am33xx-for-v3.7. All of these are upstream. > > Then I did a test merge with your commit > 219e2d6f43760509a0f0a084e8aa4711efb78c56: > > git checkout -b temp_tmlind_merge > git reset --hard 219e2d6f43760509a0f0a084e8aa4711efb78c56 > git merge omap-devel-b-c-2-for-3.7 > > There are two conflicts, both trivial, and the patch below is how they got > resolved here. > > Then probably you'll want to add Santosh's branch back in on top of that. OK thanks, that should work. The nasty merge conflicts seem to have been caused by mostly commit df3d17e0 (ARM: pmu: remove arm_pmu_type enumeration) that easily causes a nasty mis-merge of omap_init_pmu() and omap_init_rng() without removing omap_init_pmu() which your patches move to a different location. Regards, Tony
On Sun, 23 Sep 2012, Tony Lindgren wrote: > OK thanks, that should work. The nasty merge conflicts seem to have been > caused by mostly commit df3d17e0 (ARM: pmu: remove arm_pmu_type enumeration) > that easily causes a nasty mis-merge of omap_init_pmu() and omap_init_rng() > without removing omap_init_pmu() which your patches move to a different > location. OK thanks. From now on, will make sure that merge window pull requests are based on any upstream cleanup series that affect the same code. - Paul