generic RTC support for PPC
PATCH 1/1 generic RTC support for PPC
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
arch/powerpc/Kconfig +6 -0
@@ -687,6 +687,12 @@ config TAU_AVERAGE If in doubt, say N here. +config PPC_GENRTC + bool "Generic RTC support" + help + Support for using regular RTC registered with the RTC framework + as the main hardware clock on powerpc. + endmenu source arch/powerpc/platforms/embedded6xx/Kconfig
arch/powerpc/sysdev/Makefile +1 -0
@@ -22,4 +22,5 @@ endif ifeq ($(ARCH),powerpc) obj-$(CONFIG_MTD) += rom.o obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o +obj-$(CONFIG_PPC_GENRTC) += genrtc.o endif
arch/powerpc/sysdev/genrtc.c new file +76 -0
76 lines not on this page · raw message
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
Now, I know I'm a bit late, and I've been quiet of late, but, um, why is there anything other than the RTC class stuff being used? I know drivers/char/genrtc.c isn't gone yet, but really, it should be in the process of being phased out. IMHO, it should depend on !POWERPC (or whatever the magic is to allow arch/ppc && !arch/powerpc).
Signature · 1 line
Tom Rini
Quoted 5 lines · Tom Rini
Quoted 3 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
Quoted 8 lines
Quoted 2 lines
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
Now, I know I'm a bit late, and I've been quiet of late, but, um, why is there anything other than the RTC class stuff being used? I know
drivers/char/genrtc.cisn't gone yet, but really, it should be in the process of being phased out. IMHO, it should depend on !POWERPC (or whatever the magic is to allowarch/ppc&& !arch/powerpc).
I think the problem was calling the RTC class code from the place's we use rtc in ppc had locking issues or something like that.
- k
Quoted 18 lines · Kumar Gala
Quoted 8 lines · Tom Rini
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
Quoted 6 lines
Now, I know I'm a bit late, and I've been quiet of late, but, um, why is
there anything other than the RTC class stuff being used? I knowdrivers/char/genrtc.cisn't gone yet, but really, it should be in the process of being phased out. IMHO, it should depend on !POWERPC (or whatever the magic is to allowarch/ppc&& !arch/powerpc).
Quoted 2 lines
I think the problem was calling the RTC class code from the place's we use rtc in ppc had locking issues or something like that.
Yes, and it does a direct call into the driver instead of using the subsystem, exporting the symbol from the driver. Not a very pretty solution but it's possible that the genrtc stuff wasn't available when it was first implemented.
-Olof
Quoted 19 lines · Olof Johansson
Quoted 18 lines · Kumar Gala
Quoted 14 lines · Tom Rini
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
Now, I know I'm a bit late, and I've been quiet of late, but, um, why is
there anything other than the RTC class stuff being used? I knowdrivers/char/genrtc.cisn't gone yet, but really, it should be in the process of being phased out. IMHO, it should depend on !POWERPC (or whatever the magic is to allowarch/ppc&& !arch/powerpc).
Quoted 2 lines
Quoted 2 lines
I think the problem was calling the RTC class code from the place's we use rtc in ppc had locking issues or something like that.
Sounds like the RTC class code needs to be fixed up then. There's really no good reason for drivers/char/genrtc.c to live anymore, a better 'generic rtc' driver set exists now.
Quoted 4 lines
Yes, and it does a direct call into the driver instead of using the subsystem, exporting the symbol from the driver. Not a very pretty solution but it's possible that the genrtc stuff wasn't available when it was first implemented.
genrtc is quite old, really :)
Signature · 1 line
Tom Rini
Quoted 19 lines · On Tue, 30 Jan 2007 10:03:40 -0600 [email protected] (Olof Johansson) wrote:
Quoted 18 lines · Kumar Gala
Quoted 14 lines · Tom Rini
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
Now, I know I'm a bit late, and I've been quiet of late, but, um, why is
there anything other than the RTC class stuff being used? I knowdrivers/char/genrtc.cisn't gone yet, but really, it should be in the process of being phased out. IMHO, it should depend on !POWERPC (or whatever the magic is to allowarch/ppc&& !arch/powerpc).
Quoted 8 lines
Quoted 2 lines
I think the problem was calling the RTC class code from the place's we use rtc in ppc had locking issues or something like that.
Yes, and it does a direct call into the driver instead of using the subsystem, exporting the symbol from the driver. Not a very pretty solution but it's possible that the genrtc stuff wasn't available when it was first implemented.
that's probably true.
afaict, this powerpc platform <--> RTC class code glue is totally unnecessary; RTC class sets things up fine on 83xx based boards that have rtc chips supported in RTC class (e.g., the ITX). I'm referring to the third bullet point here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116387226902131&w=2
For the MDS boards, which use the ds1374, I'd rather fix the problem properly and add a ds1374 driver to the RTC class. While Scott Wood (cc'd) has already done the port, I believe his patches are pending some patches by David Brownell.
Kim
Quoted 4 lines · Kim Phillips
For the MDS boards, which use the ds1374, I'd rather fix the problem properly and add a ds1374 driver to the RTC class. While Scott Wood (cc'd) has already done the port, I believe his patches are pending some patches by David Brownell.
I can't imagine what such patches would be, unless maybe you're referring to I2C framework updates that make it follow the driver model and support platform specific data, like an RTC alarm's IRQ number? Those will take some time.
Just submit a normal I2C driver for that RTC, and any IRQ capability can be added later. (Or as a board-specific patch, which seems to be the normal solution for I2C, though they won't go upstream.)
- Dave
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
What was the consensus in the end about this? Should it go in for 2.6.21?
Paul.
Quoted 10 lines · Paul Mackerras
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
What was the consensus in the end about this? Should it go in for 2.6.21?
Are the "scheduling while atomic" issues that existed before actually been fixed?
http://marc.theaimsgroup.com/?l=linux-kernel&m=116378523012349&w=2
- k
Quoted 11 lines · Kumar Gala
Quoted 8 lines · Paul Mackerras
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
Quoted 7 lines
Quoted 2 lines
What was the consensus in the end about this? Should it go in for 2.6.21?
Are the "scheduling while atomic" issues that existed before actually been fixed?
http://marc.theaimsgroup.com/?l=linux-kernel&m=116378523012349&w=2
My patch shouldn't do it since it uses a work queue, but that bug report was for the rtc class api instead of genrtc. It'll need something similar.
I can't even find the rtc_class_hookup code in 2.6.20, so I'm not sure just what he was running.
-Olof
Quoted 18 lines · Olof Johansson
Quoted 17 lines · Kumar Gala
Quoted 10 lines · Paul Mackerras
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
What was the consensus in the end about this? Should it go in for 2.6.21?
Are the "scheduling while atomic" issues that existed before actually been fixed?
Quoted 7 lines
My patch shouldn't do it since it uses a work queue, but that bug report was for the rtc class api instead of genrtc. It'll need something similar.
I can't even find the
rtc_class_hookupcode in 2.6.20, so I'm not sure just what he was running.
Not 100% sure but we did back out some of the patches to arch/powerpc code related to this.
- k
Quoted 30 lines · On Tue, 6 Feb 2007 10:16:55 -0600 Kumar Gala <[email protected]> wrote:
Quoted 27 lines · Olof Johansson
Quoted 13 lines · Kumar Gala
Quoted 10 lines · Paul Mackerras
Quoted 7 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they
are not already defined (and an RTC is registered in the system).This should make it possible to remove the hideous direct access used
in some of the 83xx platforms.Quoted 7 lines
Quoted 2 lines
What was the consensus in the end about this? Should it go in for 2.6.21?
Are the "scheduling while atomic" issues that existed before actually been fixed?
http://marc.theaimsgroup.com/?l=linux-kernel&m=116378523012349&w=2
My patch shouldn't do it since it uses a work queue, but that bug report
was for the rtc class api instead of genrtc. It'll need something similar.
Quoted 6 lines
Quoted 2 lines
I can't even find the
rtc_class_hookupcode in 2.6.20, so I'm not sure just what he was running.Not 100% sure but we did back out some of the patches to
arch/powerpccode related to this.
hwclock works fine here without this patch. So unless there is a dependency I'm unaware of, this patch should not go into 2.6.21.
I'll send a patch out to remove the ds1374_[gs]et_rtc_time cruft from the 83xxMDS platform files when the ds1374 rtc class support patch goes in.
Kim
Quoted 10 lines · Paul Mackerras
Quoted 5 lines · Olof Johansson
Make the PPC RTC functions use the generic RTC infrastructure if they are not already defined (and an RTC is registered in the system).
This should make it possible to remove the hideous direct access used in some of the 83xx platforms.
What was the consensus in the end about this? Should it go in for 2.6.21?
Sounds like Tom Rini was strongly against it since the rtc class api should be the way to do it now. I don't care much either way, and it's not urgent for 2.6.21. Leave it out for now, I had written it off already myself.
-Olof