| Message ID | 1351613819.6199.14.camel@hornet (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Oct 30, 2012 at 04:16:59PM +0000, Pawel Moll wrote: > Hi Stephen, > > On Mon, 2012-10-29 at 20:24 +0000, Stephen Warren wrote: > > 1) At compile-time: v2m_timer_init() and v2m_dt_timer_init() reference > > functions vexpress_clk_init() and vexpress_clk_of_init() respectively, > > which don't appear anywhere in the source tree. > > There was a glitch between clk-next and arm-soc - it should be fine > starting with next-20121030. The problem is still there - my builds of my tree plus arm-soc are continuing to fail with: arch/arm/mach-vexpress/built-in.o: In function `v2m_timer_init': reset.c:(.init.text+0xe0): undefined reference to `vexpress_clk_init' arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init': reset.c:(.init.text+0x114): undefined reference to `vexpress_clk_of_init' My guess is you have a dependency between the clk-next tree and arm-soc which you haven't told the arm-soc people about.
On Mon, Nov 05, 2012 at 09:35:32AM +0000, Russell King - ARM Linux wrote: > On Tue, Oct 30, 2012 at 04:16:59PM +0000, Pawel Moll wrote: > > Hi Stephen, > > > > On Mon, 2012-10-29 at 20:24 +0000, Stephen Warren wrote: > > > 1) At compile-time: v2m_timer_init() and v2m_dt_timer_init() reference > > > functions vexpress_clk_init() and vexpress_clk_of_init() respectively, > > > which don't appear anywhere in the source tree. > > > > There was a glitch between clk-next and arm-soc - it should be fine > > starting with next-20121030. > > The problem is still there - my builds of my tree plus arm-soc are > continuing to fail with: > > arch/arm/mach-vexpress/built-in.o: In function `v2m_timer_init': > reset.c:(.init.text+0xe0): undefined reference to `vexpress_clk_init' > arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init': > reset.c:(.init.text+0x114): undefined reference to `vexpress_clk_of_init' > > My guess is you have a dependency between the clk-next tree and arm-soc > which you haven't told the arm-soc people about. Oh, and the above seems to affect all my kautobuilds for any ARM Ltd development platform - it's not just vexpress which is affected by this anymore.
On Mon, 2012-11-05 at 09:45 +0000, Russell King - ARM Linux wrote: > On Mon, Nov 05, 2012 at 09:35:32AM +0000, Russell King - ARM Linux wrote: > > On Tue, Oct 30, 2012 at 04:16:59PM +0000, Pawel Moll wrote: > > > There was a glitch between clk-next and arm-soc - it should be fine > > > starting with next-20121030. > > > > The problem is still there - my builds of my tree plus arm-soc are > > continuing to fail with: > > > > arch/arm/mach-vexpress/built-in.o: In function `v2m_timer_init': > > reset.c:(.init.text+0xe0): undefined reference to `vexpress_clk_init' > > arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init': > > reset.c:(.init.text+0x114): undefined reference to `vexpress_clk_of_init' > > > > My guess is you have a dependency between the clk-next tree and arm-soc > > which you haven't told the arm-soc people about. > > Oh, and the above seems to affect all my kautobuilds for any ARM Ltd > development platform - it's not just vexpress which is affected by this > anymore. I've just successfully built defconfigs for vexpress, versatile and realview with next-20121105 so I guess Arnd simply didn't have time last week (the Connect event) to sort out the arm-soc tree... Arnd, will you pull the vexpress-clk-soc (containing, as you suggested, the soc stuff rebased on top of the clk branch) or do you want me to do something else? Thanks! Pawe?
On Monday 05 November 2012, Pawel Moll wrote: > On Mon, 2012-11-05 at 09:45 +0000, Russell King - ARM Linux wrote: > > On Mon, Nov 05, 2012 at 09:35:32AM +0000, Russell King - ARM Linux wrote: > > > On Tue, Oct 30, 2012 at 04:16:59PM +0000, Pawel Moll wrote: > > > > There was a glitch between clk-next and arm-soc - it should be fine > > > > starting with next-20121030. > > > > > > The problem is still there - my builds of my tree plus arm-soc are > > > continuing to fail with: > > > > > > arch/arm/mach-vexpress/built-in.o: In function `v2m_timer_init': > > > reset.c:(.init.text+0xe0): undefined reference to `vexpress_clk_init' > > > arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init': > > > reset.c:(.init.text+0x114): undefined reference to `vexpress_clk_of_init' > > > > > > My guess is you have a dependency between the clk-next tree and arm-soc > > > which you haven't told the arm-soc people about. > > > > Oh, and the above seems to affect all my kautobuilds for any ARM Ltd > > development platform - it's not just vexpress which is affected by this > > anymore. > > I've just successfully built defconfigs for vexpress, versatile and > realview with next-20121105 so I guess Arnd simply didn't have time last > week (the Connect event) to sort out the arm-soc tree... > > Arnd, will you pull the vexpress-clk-soc (containing, as you suggested, > the soc stuff rebased on top of the clk branch) or do you want me to do > something else? Sorry for not getting back to this earlier. It was indeed a very busy week and I did not manage to pull in any branches. I've just tried pulling in your branch again, but it appears unchanged: The patches are still based on 807e45b328, which is a different commit from bcd6f569e874 that is in Mike's tree. Please do as I asked you before and rebase on top of the commit that you sent him, and make sure that this is a commit that Mike never rebases. Arnd
On Monday 05 November 2012, Pawel Moll wrote: > On Mon, 2012-11-05 at 16:47 +0000, Arnd Bergmann wrote: > > I've just tried pulling in your branch again, but it appears unchanged: > > The patches are still based on 807e45b328, which is a different commit > > from bcd6f569e874 that is in Mike's tree. Please do as I asked you before > > and rebase on top of the commit that you sent him, > > Ok, I think I got the idea now. Sorry about not catching up straight > away... > > The following changes since commit bcd6f569e87471d7f104bd9497f0b516a3b12e32: > > clk: Common clocks implementation for Versatile Express (2012-10-29 11:08:03 -0700) > > are available in the git repository at: > > git://git.linaro.org/people/pawelmoll/linux.git vexpress-clk-soc > > for you to fetch changes up to 433683a66401adb0150792e725cc4f631c94de46: Ok, thanks! I've put it into the next/soc2 branch now, separate from the earlier next/soc branch, since we now have a dependency on another branch. > ARM: vexpress: Remove motherboard dependencies in the DTS files (2012-11-05 17:09:52 +0000) > > > and make sure that this is a commit that Mike never rebases. > > Uh. Mike, is your clk-next subject to rebases? On a related note, there are other patches below this one now: clk: Common clocks implementation for Versatile Express clk: Versatile Express clock generators ("osc") driver CLK: clk-twl6040: Initial clock driver for OMAP4+ McPDM fclk clock clk: fix return value check in sirfsoc_of_clk_init() clk: fix return value check in of_fixed_clk_setup() clk: ux500: Update sdmmc clock to 100MHz for u8500 clk: ux500: Support prcmu ape opp voltage clock mfd: dbx500: Export prmcu_request_ape_opp_100_voltage clk: Don't return negative numbers for unsigned values with !clk clk: Fix documentation typos clk: Document .is_enabled op clk: SPEAr: Vco-pll: Fix compilation warning Mike, do you prefer us to wait for those to make it into v3.8-rc1 before pushing the patches from Pawel, or can we just send the entire branch along with the other changes? FWIW, there is a way to avoid dependencies like this if the patches that are required in two branches are based directly on an -rc release and then merged into the two maintainer trees, rather than having one maintainer tree pull in (part of) the history of another one. Arnd
On Mon, 2012-11-05 at 17:52 +0000, Arnd Bergmann wrote: > Mike, do you prefer us to wait for those to make it into v3.8-rc1 before > pushing the patches from Pawel, or can we just send the entire branch > along with the other changes? Or, maybe, you prefer to remove the vexpress patches from clk-next completely (if it is to be rebased) and let them go only through arm-soc? (just asking) Pawe?
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c index 059d6b1..99e89a8 100644 --- a/drivers/mfd/vexpress-sysreg.c +++ b/drivers/mfd/vexpress-sysreg.c @@ -474,7 +474,6 @@ static int __init vexpress_sysreg_init(void) } core_initcall(vexpress_sysreg_init); - #if defined(CONFIG_LEDS_CLASS) struct vexpress_sysreg_led { @@ -526,6 +525,9 @@ static int __init vexpress_sysreg_init_leds(void) struct vexpress_sysreg_led *led; int i; + if (!vexpress_sysreg_base) + return 0; + /* Clear all user LEDs */ writel(0, vexpress_sysreg_base + SYS_LED);