From: Tony Lindgren <tony@atomide.com>
To: Felipe Balbi <balbi@ti.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] ARM: OMAP2: use correct timer function for AM43XX and TI81XX
Date: Thu, 19 Nov 2015 10:33:45 -0800 [thread overview]
Message-ID: <20151119183345.GT2498@atomide.com> (raw)
In-Reply-To: <87io4yezi9.fsf@saruman.tx.rr.com>
* Felipe Balbi <balbi@ti.com> [151119 08:16]:
>
> Hi,
>
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Monday 16 November 2015 15:13:55 Felipe Balbi wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> > AM43XX and TI81XX use omap3_gptimer_timer_init(), but that is only
> >> > built into the kernel for OMAP3 and AM33XX, otherwise we get:
> >> >
> >> > arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x124): undefined reference to `omap3_gptimer_timer_init'
> >> >
> >> > This changes the Kconfig logic for building the function to
> >> > match the callers. Consequently, we no longer need to build
> >> > the omap3_secure_sync32k_timer_init and omap4_local_timer_init
> >> > for the platforms that have been moved over to other functions.
> >> >
> >> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >>
> >> no, AM43xx uses omap4_local_timer_init(), there's already a fix in
> >> Tony's tree IIRC.
> > ...
> >
> >> care to provide a defconfig which would cause a build error ?
> >
> > My mistake, the code has changed several times and I adapted it to
> > the latest version each time, but the version I sent out is indeed
> > useless.
> >
> > The only hunk that still makes sense is
> >
> > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> > index b18ebbefae09..b7ab09cc5ca2 100644
> > --- a/arch/arm/mach-omap2/timer.c
> > +++ b/arch/arm/mach-omap2/timer.c
> > @@ -494,7 +494,7 @@ void __init omap_init_time(void)
> > clocksource_probe();
> > }
> >
> > -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
> > +#if defined(CONFIG_ARCH_OMAP3)
> > void __init omap3_secure_sync32k_timer_init(void)
> > {
> > __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
> >
> >
> > but that is harmless as it does not cause a build error, just a few extra
> > bytes for an unused function in a AM43XX-only configuration.
>
> I think that's still useful. Tony ?
Yeah makes sense to me. We already have omap4_sync32k_timer_init() when
am437x PM gets enabled.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2: use correct timer function for AM43XX and TI81XX
Date: Thu, 19 Nov 2015 10:33:45 -0800 [thread overview]
Message-ID: <20151119183345.GT2498@atomide.com> (raw)
In-Reply-To: <87io4yezi9.fsf@saruman.tx.rr.com>
* Felipe Balbi <balbi@ti.com> [151119 08:16]:
>
> Hi,
>
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Monday 16 November 2015 15:13:55 Felipe Balbi wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> > AM43XX and TI81XX use omap3_gptimer_timer_init(), but that is only
> >> > built into the kernel for OMAP3 and AM33XX, otherwise we get:
> >> >
> >> > arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x124): undefined reference to `omap3_gptimer_timer_init'
> >> >
> >> > This changes the Kconfig logic for building the function to
> >> > match the callers. Consequently, we no longer need to build
> >> > the omap3_secure_sync32k_timer_init and omap4_local_timer_init
> >> > for the platforms that have been moved over to other functions.
> >> >
> >> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >>
> >> no, AM43xx uses omap4_local_timer_init(), there's already a fix in
> >> Tony's tree IIRC.
> > ...
> >
> >> care to provide a defconfig which would cause a build error ?
> >
> > My mistake, the code has changed several times and I adapted it to
> > the latest version each time, but the version I sent out is indeed
> > useless.
> >
> > The only hunk that still makes sense is
> >
> > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> > index b18ebbefae09..b7ab09cc5ca2 100644
> > --- a/arch/arm/mach-omap2/timer.c
> > +++ b/arch/arm/mach-omap2/timer.c
> > @@ -494,7 +494,7 @@ void __init omap_init_time(void)
> > clocksource_probe();
> > }
> >
> > -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
> > +#if defined(CONFIG_ARCH_OMAP3)
> > void __init omap3_secure_sync32k_timer_init(void)
> > {
> > __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
> >
> >
> > but that is harmless as it does not cause a build error, just a few extra
> > bytes for an unused function in a AM43XX-only configuration.
>
> I think that's still useful. Tony ?
Yeah makes sense to me. We already have omap4_sync32k_timer_init() when
am437x PM gets enabled.
Regards,
Tony
next prev parent reply other threads:[~2015-11-19 18:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 21:10 [PATCH] ARM: OMAP2: use correct timer function for AM43XX and TI81XX Arnd Bergmann
2015-11-16 21:10 ` Arnd Bergmann
2015-11-16 21:13 ` Felipe Balbi
2015-11-16 21:13 ` Felipe Balbi
2015-11-19 15:57 ` Arnd Bergmann
2015-11-19 15:57 ` Arnd Bergmann
2015-11-19 16:15 ` Felipe Balbi
2015-11-19 16:15 ` Felipe Balbi
2015-11-19 18:33 ` Tony Lindgren [this message]
2015-11-19 18:33 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151119183345.GT2498@atomide.com \
--to=tony@atomide.com \
--cc=arnd@arndb.de \
--cc=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.