* [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
@ 2006-09-26 22:46 Kim Phillips
2006-09-27 4:34 ` Kumar Gala
0 siblings, 1 reply; 6+ messages in thread
From: Kim Phillips @ 2006-09-26 22:46 UTC (permalink / raw)
To: linuxppc-dev
enable generic rtc hook for the MPC8349 mITX.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/platforms/83xx/mpc834x_itx.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 969fbb6..8c676d7 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
return 1;
}
+#ifdef CONFIG_RTC_CLASS
+late_initcall(rtc_class_hookup);
+#endif
+
define_machine(mpc834x_itx) {
.name = "MPC834x ITX",
.probe = mpc834x_itx_probe,
--
1.4.2.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
2006-09-26 22:46 [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX Kim Phillips
@ 2006-09-27 4:34 ` Kumar Gala
2006-09-27 15:58 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Kumar Gala @ 2006-09-27 4:34 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
> enable generic rtc hook for the MPC8349 mITX.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>
> ---
> arch/powerpc/platforms/83xx/mpc834x_itx.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> powerpc/platforms/83xx/mpc834x_itx.c
> index 969fbb6..8c676d7 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> return 1;
> }
>
> +#ifdef CONFIG_RTC_CLASS
> +late_initcall(rtc_class_hookup);
> +#endif
Any reason we can't just do this in setup_arch?
- k
> +
> define_machine(mpc834x_itx) {
> .name = "MPC834x ITX",
> .probe = mpc834x_itx_probe,
> --
> 1.4.2.1
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
2006-09-27 4:34 ` Kumar Gala
@ 2006-09-27 15:58 ` Tom Rini
2006-09-28 4:43 ` Kim Phillips
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2006-09-27 15:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
[snip]
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > powerpc/platforms/83xx/mpc834x_itx.c
> > index 969fbb6..8c676d7 100644
> > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > return 1;
> > }
> >
> > +#ifdef CONFIG_RTC_CLASS
> > +late_initcall(rtc_class_hookup);
> > +#endif
>
> Any reason we can't just do this in setup_arch?
I think because of rtc-over-i2c and similar where we need the whole rest
of the system 'up' before we can try and use the RTC (which might not be
the case for this specific board, but for consistency it looks like a
good thing to always do it like this).
--
Tom Rini
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
2006-09-27 15:58 ` Tom Rini
@ 2006-09-28 4:43 ` Kim Phillips
2006-09-29 23:25 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Kim Phillips @ 2006-09-28 4:43 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
On Wed, 27 Sep 2006 08:58:53 -0700
Tom Rini <trini@kernel.crashing.org> wrote:
> On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> > On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
> [snip]
> > > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > > powerpc/platforms/83xx/mpc834x_itx.c
> > > index 969fbb6..8c676d7 100644
> > > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > > return 1;
> > > }
> > >
> > > +#ifdef CONFIG_RTC_CLASS
> > > +late_initcall(rtc_class_hookup);
> > > +#endif
> >
> > Any reason we can't just do this in setup_arch?
>
> I think because of rtc-over-i2c and similar where we need the whole rest
> of the system 'up' before we can try and use the RTC (which might not be
> the case for this specific board, but for consistency it looks like a
> good thing to always do it like this).
>
this is indeed the case, as with the static assignment of the ppc_md rtc_time functions in define_machine. In the early assignment case, the kernel oopses early in rtc_class_open().
During testing I noticed hwclock get/set operations worked even without hooking up with the ppc_md rtc_time functions. Turns out this rtc_class provides access to the RTC to the whole kernel and userspace:
http://lkml.org/lkml/2005/12/20/220
so, both of these patches are really unnecessary, unless there's a genuine consumer in arch/powerpc that I can't find (I'm assuming get_boot_time() isn't one of them since it gets called way too early in the rtc-over-i2c based platform case).
So we should just configure RTC_CLASS and the specific chip and we're done. :)
Kim
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX
2006-09-28 4:43 ` Kim Phillips
@ 2006-09-29 23:25 ` Tom Rini
2006-10-02 1:51 ` Mark A. Greer
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2006-09-29 23:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
On Wed, Sep 27, 2006 at 11:43:04PM -0500, Kim Phillips wrote:
> On Wed, 27 Sep 2006 08:58:53 -0700
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > On Tue, Sep 26, 2006 at 11:34:43PM -0500, Kumar Gala wrote:
> > > On Sep 26, 2006, at 5:46 PM, Kim Phillips wrote:
> > [snip]
> > > > diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/
> > > > powerpc/platforms/83xx/mpc834x_itx.c
> > > > index 969fbb6..8c676d7 100644
> > > > --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > > +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> > > > @@ -109,6 +109,10 @@ static int __init mpc834x_itx_probe(void
> > > > return 1;
> > > > }
> > > >
> > > > +#ifdef CONFIG_RTC_CLASS
> > > > +late_initcall(rtc_class_hookup);
> > > > +#endif
> > >
> > > Any reason we can't just do this in setup_arch?
> >
> > I think because of rtc-over-i2c and similar where we need the whole rest
> > of the system 'up' before we can try and use the RTC (which might not be
> > the case for this specific board, but for consistency it looks like a
> > good thing to always do it like this).
> >
> this is indeed the case, as with the static assignment of the ppc_md rtc_time functions in define_machine. In the early assignment case, the kernel oopses early in rtc_class_open().
>
> During testing I noticed hwclock get/set operations worked even without hooking up with the ppc_md rtc_time functions. Turns out this rtc_class provides access to the RTC to the whole kernel and userspace:
>
> http://lkml.org/lkml/2005/12/20/220
>
> so, both of these patches are really unnecessary, unless there's a genuine consumer in arch/powerpc that I can't find (I'm assuming get_boot_time() isn't one of them since it gets called way too early in the rtc-over-i2c based platform case).
>
> So we should just configure RTC_CLASS and the specific chip and we're done. :)
Does this mean we can then rip out some existing code, so long as
there's associated cleanup / rtc class support additions?
--
Tom Rini
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-10-02 1:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-26 22:46 [PATCH 2/2] enable generic rtc hook for the MPC8349 mITX Kim Phillips
2006-09-27 4:34 ` Kumar Gala
2006-09-27 15:58 ` Tom Rini
2006-09-28 4:43 ` Kim Phillips
2006-09-29 23:25 ` Tom Rini
2006-10-02 1:51 ` Mark A. Greer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).