generic MIPS RTC driver
Subsystems (3)
RFC 1/1 generic MIPS RTC driver
For many MIPS boards that start to use CONFIG_NEW_TIME_C, two rtc operations are implemented, rtc_get_time() and rtc_set_time().
It is possible to write a simple generic RTC driver that is based on these two ops and can do simple RTC read&write ops.
In other words, with such a driver, once you implemented rtc_get_time() and rtc_set_time(), which is required by the kernel anyway, you will automatically get a free /dev/rtc/ driver.
This is the idea behind the generic MIPS rtc driver. See the patch below.
Right now the feature is rather limited, due to the thin abstraction we are having with rtc ops. But apparently the implementation is good enough to make hwclock program happy.
Any comments?
Jun
/*
* A simple generic Real Time Clock interface for Linux/MIPS
*
* Copyright (C) 1996 Paul Gortmaker
*
* Copyright (C) 2001 Monta Vista Software
* Author Jun Sun, [email protected] or [email protected]
*
* This is a simple generic RTC driver for MIPS boards configured * with CONFIG_NEW_TIME_C. For now, it makes use of the two * abstract kernel RTC functions introduced in include/asm-mips/time.h: * * extern unsigned long (*rtc_get_time)(void); * extern int (*rtc_set_time)(unsigned long); * * It uses the same protocol as the original drivers/char/rtc.c driver, * but only implements two ioctls: RTC_RD_TIME and RTC_SET_TIME. * * TODO : * * 1. we can extend the null rtc ops defined in arch/mips/time.c to * at least record the elapsed time (by recording/checking jiffies) * This way RTC_RD_TIME and RTC_SET_TIME will make more sense. * (Maybe not. A machine without a real RTC is broken anymore. * Just a thought.) * * 2. If we make use of timer bh, we can emulate many RTC functions * such as RTC alarm interrupt, periodic interrupts, etc. * * 3. It is possible to extend the kernel RTC abstractions to more * than two functions, so that perhaps we can implement more * full-featured RTC driver and also have a better abstraction * to support more RTC hardware than the original RTC driver. * It needs to be done very carefully.
*
* Change Log :
* v1.0 - [jsun] initial version
*/
Documentation/Configure.help renamed from Documentation/Configure.help.orig +11 -0
@@ -15163,6 +15163,17 @@ #EFI Real Time Clock Services #CONFIG_EFI_RTC +Generic MIPS RTC Support +CONFIG_MIPS_RTC + + If your machine is a MIPS machine, this option provides a simple, + generic RTC driver for /dev/rtc device. It only implements two IOCTL + operations of the standard PC RTC driver: RTC_RD_TIME and RTC_SET_TIME. + It is sufficient to run hwclock program. + + You should say Y here if there is no machine-specific RTC driver for your + MIPS machine but you do want a simple RTC driver for your RTC device. + Tadpole ANA H8 Support CONFIG_H8 The Hitachi H8/337 is a microcontroller used to deal with the power
drivers/char/Config.in renamed from drivers/char/Config.in.orig +3 -0
@@ -194,6 +194,9 @@ if [ "$CONFIG_OBSOLETE" = "y" -a "$CONFIG_ALPHA_BOOK1" = "y" ]; then bool 'Tadpole ANA H8 Support' CONFIG_H8 fi +if [ "$CONFIG_MIPS" = "y" -a "$CONFIG_NEW_TIME_C" = "y" ]; then + tristate 'Generic MIPS RTC Support' CONFIG_MIPS_RTC +fi tristate 'Double Talk PC internal speech card support' CONFIG_DTLK tristate 'Siemens R3964 line discipline' CONFIG_R3964
drivers/char/Makefile renamed from drivers/char/Makefile.orig +1 -0
@@ -194,6 +194,7 @@ obj-$(CONFIG_PC110_PAD) += pc110pad.o obj-$(CONFIG_RTC) += rtc.o obj-$(CONFIG_EFI_RTC) += efirtc.o +obj-$(CONFIG_MIPS_RTC) += mips_rtc.o ifeq ($(CONFIG_PPC),) obj-$(CONFIG_NVRAM) += nvram.o endif
drivers/char/mips_rtc.c renamed from drivers/char/mips_rtc.c.orig +221 -0
221 lines not on this page · raw message
Quoted 11 lines · Jun Sun
For many MIPS boards that start to use
CONFIG_NEW_TIME_C, two rtc operations are implemented,rtc_get_time()andrtc_set_time().It is possible to write a simple generic RTC driver that is based on these two ops and can do simple RTC read&write ops.
In other words, with such a driver, once you implemented
rtc_get_time()andrtc_set_time(), which is required by the kernel anyway, you will automatically get a free/dev/rtc/driver.This is the idea behind the generic MIPS rtc driver. See the patch below.
Oh no, don't tell me we now have (at least) _three_ of these floating around :-)
- On m68k, we have drivers/char/genrtc.c (not yet merged, check out CVS, see
http://linux-m68k-cvs.apia.dhs.org/).
- On PPC, we have drivers/macintosh/rtc.c.
- On MIPS, we now have your drivers/char/mips_rtc.c.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 6 lines · Geert Uytterhoeven
Quoted 5 lines
In other words, with such a driver, once you implemented
rtc_get_time()andrtc_set_time(), which is required by the kernel anyway, you will automatically get a free/dev/rtc/driver.This is the idea behind the generic MIPS rtc driver. See the patch below.
Quoted 7 lines
Oh no, don't tell me we now have (at least) _three_ of these floating around :-)
- On m68k, we have
drivers/char/genrtc.c(not yet merged, check out CVS, seehttp://linux-m68k-cvs.apia.dhs.org/).- On PPC, we have
drivers/macintosh/rtc.c.
- On MIPS, we now have yourdrivers/char/mips_rtc.c.
Agreed, what's wrong with drivers/char/rtc.c? It even works for the
DECstation which maps its RTC in an unusual (but nice) way -- it's just a matter of initializing rtc_ops appropriately. See arch/mips/dec/rtc-dec.c for an example.
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 10 lines · Maciej W. Rozycki
Quoted 9 lines · Geert Uytterhoeven
Quoted 5 lines
In other words, with such a driver, once you implemented
rtc_get_time()andrtc_set_time(), which is required by the kernel anyway, you will automatically get a free/dev/rtc/driver.This is the idea behind the generic MIPS rtc driver. See the patch below.
Oh no, don't tell me we now have (at least) _three_ of these floating around :-)
Quoted 6 lines
Quoted 4 lines
- On m68k, we have
drivers/char/genrtc.c(not yet merged, check out CVS, seehttp://linux-m68k-cvs.apia.dhs.org/).- On PPC, we have
drivers/macintosh/rtc.c.
- On MIPS, we now have yourdrivers/char/mips_rtc.c.Agreed, what's wrong with
drivers/char/rtc.c? It even works for the
It's for MC146818 RTCs only.
Quoted 6 lines
DECstation which maps its RTC in an unusual (but nice) way -- it's just a matter of initializing
rtc_opsappropriately. Seearch/mips/dec/rtc-dec.cfor an example.Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.
Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a /dev/rtc-compatible abstraction on top of it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 5 lines · Geert Uytterhoeven
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.
OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one. Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 11 lines · Maciej W. Rozycki
Quoted 5 lines · Geert Uytterhoeven
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one. Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.
I agree. We don't have arch specific network drivers so why have arch specific rtc drivers.
Pete
Quoted 10 lines · Pete Popov
Quoted 8 lines · Maciej W. Rozycki
Quoted 5 lines · Geert Uytterhoeven
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.
Quoted 7 lines
Quoted 3 lines
OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one. Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.I agree. We don't have arch specific network drivers so why have arch specific rtc drivers.
Because we can have a free RTC driver working once you get kernel working.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 16 lines · Jun Sun
Quoted 14 lines · Pete Popov
Quoted 11 lines · Maciej W. Rozycki
Quoted 5 lines · Geert Uytterhoeven
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one. Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.
Quoted 6 lines
Quoted 3 lines
I agree. We don't have arch specific network drivers so why have arch specific rtc drivers.
Because we can have a free RTC driver working once you get kernel working.
Actually there is a longer answer with a little bit of the background info.
Kernel needs to know about the real calendar time when it boots up. And optionally it may write to RTC (based on the assumption that kernel timer is more accurate than RTC clock). So it already has abstraction, one form or another, to do RTC read/write.
Based on these abstractons you can provide a hardware-independent RTC driver, with RTC read/write operations.
Before CONFIG_NEW_TIME_C is introduced, each MIPS board has its own time service routine, which means, even if RTC driver wants to utilize the abstraction, it will be only for that board only.
After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common. Therefore, we can afford a MIPS-common generic RTC driver.
If that abstraction ever becomes Linux-common code, then the generic RTC driver will essentially be a Linux-common, device-indpendent driver.
For most MIPS machine, we need /dev/rtc to merely set time and read time. The generic driver should suffice. Otherwire, you can wirte a complete one for a specific board or a specific chip.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 26 lines · Jun Sun
Quoted 16 lines · Jun Sun
Quoted 14 lines · Pete Popov
Quoted 11 lines · Maciej W. Rozycki
Quoted 5 lines · Geert Uytterhoeven
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one. Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.Quoted 6 lines
Quoted 3 lines
I agree. We don't have arch specific network drivers so why have arch specific rtc drivers.
Because we can have a free RTC driver working once you get kernel working.
Actually there is a longer answer with a little bit of the background info.
Quoted 7 lines
Kernel needs to know about the real calendar time when it boots up. And optionally it may write to RTC (based on the assumption that kernel timer is more accurate than RTC clock). So it already has abstraction, one form or another, to do RTC read/write.
Based on these abstractons you can provide a hardware-independent RTC driver, with RTC read/write operations.
Right.
Quoted 6 lines
Before
CONFIG_NEW_TIME_Cis introduced, each MIPS board has its own time service routine, which means, even if RTC driver wants to utilize the abstraction, it will be only for that board only.After
CONFIG_NEW_TIME_Cis introduced, that RTC abstract becomes MIPS-common. Therefore, we can afford a MIPS-common generic RTC driver.
No. This sounds _exactly_ like the PPC driver. What we need to do, and what I intend to do in 2.5 is make this a bit more generic so thatr any arch can fill out some infos and say we read like this, we write like that and that's that.
Quoted 2 lines
If that abstraction ever becomes Linux-common code, then the generic RTC driver will essentially be a Linux-common, device-indpendent driver.
Yeap. I wanna do this in 2.5.
Quoted 3 lines
For most MIPS machine, we need
/dev/rtcto merely set time and read time. The generic driver should suffice. Otherwire, you can wirte a complete one for a specific board or a specific chip.
The 'rtc' driver in drivers/char does read, write, some ioctls and a /proc bit. We can make this a bit more 'generic'
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 11 lines · Maciej W. Rozycki
Quoted 5 lines · Geert Uytterhoeven
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one.
You *can* write a chip specific driver in addition to this generic one if you want. Presumably the chip-specific one provides more operations than just read/write date.
Quoted 3 lines
Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.
Don't quite understand this statement.
If everybody uses the generic rtc driver, there will be only one copy of it. It will prevent zillions copies of similar thing.
Note that hardware specifics are already abstracted by rtc_set_time() and rtc_get_time() routines. The generic RTC driver makes use of them and has no RTC chip or machine dependent code.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 6 lines · Jun Sun
Quoted 2 lines
OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one.You *can* write a chip specific driver in addition to this generic one if you want. Presumably the chip-specific one provides more operations than just read/write date.
Then why make this driver MIPS-specific?
Quoted 4 lines
Quoted 2 lines
Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips.
Don't quite understand this statement.
This assumed you've meant an MC146818 RTC that already has a driver for
certain (but possibly not all) configurations. Since you haven't -- just forget it.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 12 lines · Maciej W. Rozycki
Quoted 6 lines · Jun Sun
Quoted 2 lines
OK, then you need an RTC chipset-specific driver and not a CPU
architecture-specific one.You *can* write a chip specific driver in addition to this generic one if you want. Presumably the chip-specific one provides more operations than just read/write date.
Then why make this driver MIPS-specific?
I suppose one of my previous replies should answer this. Let me know if it does not.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 25 lines · Geert Uytterhoeven
Quoted 10 lines · Maciej W. Rozycki
Quoted 9 lines · Geert Uytterhoeven
Quoted 5 lines
In other words, with such a driver, once you implemented
rtc_get_time()andrtc_set_time(), which is required by the kernel anyway, you will automatically get a free/dev/rtc/driver.This is the idea behind the generic MIPS rtc driver. See the patch below.
Oh no, don't tell me we now have (at least) _three_ of these floating around :-)
Quoted 6 lines
Quoted 4 lines
- On m68k, we have
drivers/char/genrtc.c(not yet merged, check out CVS, seehttp://linux-m68k-cvs.apia.dhs.org/).- On PPC, we have
drivers/macintosh/rtc.c.
- On MIPS, we now have yourdrivers/char/mips_rtc.c.Agreed, what's wrong with
drivers/char/rtc.c? It even works for theIt's for MC146818 RTCs only.
Quoted 4 lines
DECstation which maps its RTC in an unusual (but nice) way -- it's just a matter of initializing
rtc_opsappropriately. Seearch/mips/dec/rtc-dec.cfor an example.
Quoted 6 lines
Quoted 2 lines
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.
Geert, what is the abstraction they used?
The /dev/rtc interface is highly influenced by MC146818 chip, which not all RTC devices are alike. The only fundamental thing in the driver is really the read and write time.
If their abstraction is reasonable, perhaps they can all converge to a better, more generic rtc interface.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 3 lines · Jun Sun
The
/dev/rtcinterface is highly influenced by MC146818 chip, which not all RTC devices are alike. The only fundamental thing in the driver is really the read and write time.
You need only to keep the interface, which is:
static struct file_operations rtc_fops = {
owner: THIS_MODULE,
llseek: no_llseek,
read: rtc_read,
#if RTC_IRQ
poll: rtc_poll,
#endif
ioctl: rtc_ioctl,
open: rtc_open,
release: rtc_release,
fasync: rtc_fasync,
};Of these you probably must only implement open() and ioctl() -- you may provide others as hardware permits -- see how these functions are implemented in drivers/char/rtc.c. The interface is pretty generic, IMHO.
Quoted 2 lines
If their abstraction is reasonable, perhaps they can all converge to a better, more generic rtc interface.
Just implement the ioctls given hardware permits and return -EINVAL for
others. Again, they are pretty generic: get/set the time, alarm, epoch, disable/enable various interrupts, etc. -- see include/linux/rtc.h. You may propose additional ioctls if they would be useful for particular hardware.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 26 lines · Maciej W. Rozycki
Quoted 3 lines · Jun Sun
The
/dev/rtcinterface is highly influenced by MC146818 chip, which not all RTC devices are alike. The only fundamental thing in the driver is really the read and write time.You need only to keep the interface, which is:
static struct
file_operationsrtc_fops= {owner: THIS_MODULE, llseek: no_llseek, read: rtc_read, #if RTC_IRQ poll: rtc_poll, #endif ioctl: rtc_ioctl, open: rtc_open, release: rtc_release, fasync: rtc_fasync,};
Of these you probably must only implement
open()andioctl()-- you may provide others as hardware permits -- see how these functions are implemented indrivers/char/rtc.c. The interface is pretty generic, IMHO.
Quoted 9 lines
Quoted 2 lines
If their abstraction is reasonable, perhaps they can all converge to a better, more generic rtc interface.
Just implement the ioctls given hardware permits and return
-EINVALfor
others. Again, they are pretty generic: get/set the time, alarm, epoch, disable/enable various interrupts, etc. -- seeinclude/linux/rtc.h. You may propose additional ioctls if they would be useful for particular hardware.
Basically agree.
Maybe the only thing really missing is a formal way to determine and report the capability of the driver, rather through checking the return value being -EINVAL.
I guess my original question to Geert is more on the abstraction of the RTC hardware routines, especially anything beyond rtc_read_time() and rt_write_time().
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 10 lines · Jun Sun
Quoted 7 lines · Geert Uytterhoeven
Quoted 2 lines · Maciej W. Rozycki
Unless you use a non-MC146818 RTC, which you need to write a separate
driver for anyway.Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a
/dev/rtc-compatibleabstraction on top of it.Geert, what is the abstraction they used?
At first sight, we only use get_rtc_time() and mach_hwclk().
Quoted 6 lines
The
/dev/rtcinterface is highly influenced by MC146818 chip, which not all RTC devices are alike. The only fundamental thing in the driver is really the read and write time.If their abstraction is reasonable, perhaps they can all converge to a better, more generic rtc interface.
Check out the following files from the m68k CVS tree (see
http://linux-m68k-cvs.apia.dhs.org/):
- drivers/char/genrtc.c
- include/asm-m68k/machdep.h
- include/asm-m68k/rtc.h
On PPC, they have something similar.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi,
Quoted 3 lines · Geert Uytterhoeven
Quoted 1 line
Geert, what is the abstraction they used?
At first sight, we only use
get_rtc_time()andmach_hwclk().
Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in <asm/rtc.h>, so mach_hwclk() is gone in the generic part.
Another feature is the emulation of the timer interrupt, although I have no idea which program is using this. Richard?
bye, Roman
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 5 lines · Roman Zippel
Hi,
Geert Uytterhoeven wrote:
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Geert, what is the abstraction they used?
At first sight, we only use
get_rtc_time()andmach_hwclk().Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in <
asm/rtc.h>, somach_hwclk()is gone in the generic part.
Could you please post a copy of this? I wanna go and try and get the rest of the PPC world going on it, if you didn't do that already.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 4 lines · Tom Rini
Quoted 3 lines · Roman Zippel
Quoted 2 lines · Geert Uytterhoeven
Quoted 1 line
Geert, what is the abstraction they used?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
At first sight, we only use
get_rtc_time()andmach_hwclk().Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in <
asm/rtc.h>, somach_hwclk()is gone in the generic part.Could you please post a copy of this? I wanna go and try and get the rest of the PPC world going on it, if you didn't do that already.
http://linux-m68k-cvs.apia.dhs.org/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 7 lines · Geert Uytterhoeven
Quoted 6 lines · Tom Rini
Quoted 5 lines · Roman Zippel
Quoted 3 lines · Geert Uytterhoeven
Quoted 1 line
Geert, what is the abstraction they used?
At first sight, we only use
get_rtc_time()andmach_hwclk().
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in <
asm/rtc.h>, somach_hwclk()is gone in the generic part.Could you please post a copy of this? I wanna go and try and get the rest of the PPC world going on it, if you didn't do that already.
That's the non-generic m68k version tho, yes? Or did Roman do it in that tree too?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 12 lines · Tom Rini
Quoted 11 lines · Geert Uytterhoeven
Quoted 10 lines · Tom Rini
Quoted 8 lines · Roman Zippel
Quoted 3 lines · Geert Uytterhoeven
Quoted 1 line
Geert, what is the abstraction they used?
At first sight, we only use
get_rtc_time()andmach_hwclk().Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in <
asm/rtc.h>, somach_hwclk()is gone in the generic part.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Could you please post a copy of this? I wanna go and try and get the rest of the PPC world going on it, if you didn't do that already.
That's the non-generic m68k version tho, yes? Or did Roman do it in that tree too?
That's the real one. On Q40/Q60 it provides some additional features, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi,
Quoted 4 lines · Tom Rini
Quoted 1 line
That's the non-generic m68k version tho, yes? Or did Roman do it in that tree too?
That version is even more recent than the one currently in the APUS repository. :)
But I tested it also under APUS, so you only need to provide [gs]et_rtc_time and it should work.
bye, Roman
Quoted 6 lines · Roman Zippel
Hi,
Quoted 2 lines · Geert Uytterhoeven
Quoted 1 line
Geert, what is the abstraction they used?
Quoted 7 lines
Quoted 1 line
At first sight, we only use
get_rtc_time()andmach_hwclk().Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in <
asm/rtc.h>, somach_hwclk()is gone in the generic part.
Another feature is the emulation of the timer interrupt, although I have no idea which program is using this.
hwclock and a bunch of less known porgrams like chrony. Where the interrupt can be generated its a clear win, otherwise it might be more reasonable to return EINVAL instead of trying to emulate it - presumably hwclock can use some fallback method.
Btw the interrupt need not to be hardware, for the Q40 I test a rtc register once per jiffie and generate a "soft interrupt". It could be done generic at least for m68k.
Bye
Richard
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi,
Quoted 1 line · Richard Zidlicky
hwclock and a bunch of less known porgrams like chrony.
I was playing with chrony, but it was unable to adjust the time, last weekend I switched back to ntp and that works better.
bye, Roman
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 8 lines · Roman Zippel
Hi,
Quoted 1 line · Richard Zidlicky
hwclock and a bunch of less known porgrams like chrony.
I was playing with chrony, but it was unable to adjust the time, last weekend I switched back to ntp and that works better.
some years ago chrony was the reason I wrote the Q40 rtc driver. It didn't work very well for me either, but the rtc driver was very useful in the meantime :)
Bye
Richard
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 4 lines · Richard Zidlicky
Btw the interrupt need not to be hardware, for the Q40 I test a rtc register once per jiffie and generate a "soft interrupt". It could be done generic at least for m68k.
I have written an experiemntal ptimer driver to do just this and potential more. Such a device is useful for real-time programming (e.g., when you try to implement a periodic user task).
See http://linux.junsun.net/realtime-linux/preemption-test
The driver is architecture independent (i.e., linux-common code)
Due to the different programming needs behind periodic timers (or user-level timer) and RTC operations, my vote for future work is to leave them as two separate drivers. To me, RTC is really just to read/write RTC clock.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 11 lines · Jun Sun
Quoted 4 lines · Richard Zidlicky
Btw the interrupt need not to be hardware, for the Q40 I test a rtc register once per jiffie and generate a "soft interrupt". It could be done generic at least for m68k.
I have written an experiemntal ptimer driver to do just this and potential more. Such a device is useful for real-time programming (e.g., when you try to implement a periodic user task).
Quoted 7 lines
See http://linux.junsun.net/realtime-linux/preemption-test
The driver is architecture independent (i.e., linux-common code)
Due to the different programming needs behind periodic timers (or user-level timer) and RTC operations, my vote for future work is to leave them as two separate drivers. To me, RTC is really just to read/write RTC clock.
RTC_UIE is needed (or at least very useful) to set the clock, so it belongs into a rtc driver if it can be implemented. General purpose timers are different story, btw what is wrong with setitimer that you have chosen to implement an additional driver for it?
Richard
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 17 lines · Richard Zidlicky
Quoted 15 lines · Jun Sun
Quoted 4 lines · Richard Zidlicky
Btw the interrupt need not to be hardware, for the Q40 I test a rtc register once per jiffie and generate a "soft interrupt". It could be done generic at least for m68k.
I have written an experiemntal ptimer driver to do just this and potential more. Such a device is useful for real-time programming (e.g., when you try to implement a periodic user task).
See http://linux.junsun.net/realtime-linux/preemption-test
The driver is architecture independent (i.e., linux-common code)
Quoted 8 lines
Quoted 3 lines
Due to the different programming needs behind periodic timers (or user-level timer) and RTC operations, my vote for future work is to leave them as two separate drivers. To me, RTC is really just to read/write RTC clock.
RTC_UIEis needed (or at least very useful) to set the clock, so it belongs into a rtc driver if it can be implemented. General purpose timers are different story, btw what is wrong with setitimer that you have chosen to implement an additional driver for it?
Easy of implmentation and more features.
Here is the pseudo code to do a real-time periodic task with /dev/ptimer:
void periodic_task(void)
{
fd=open("/dev/ptimer", O_RDONLY);
ioctl(fd, PTIMER_SET_PERIOD, PERIOD);
ioctl(fd, PTIMER_SET_PHASE, PHASE);
/* become realtime process */
start_realtime();
for(;;) {
/* read won't return until next instance release point */
read(fd, &count, sizeof(count));
/* do the job */
...
}
}Anybody who has used setitimer() would konw this is even simpler than the setup of itimer, let alone with itimer you still need to deal with SIGALRM signals plus some multi-thread signal handling considerations.
On the feature side, ptimer offers the exact control of phase. For example, you can have two tasks with period of 100ms, with one starting *exactly* at time t and the other starting *exactly* at t+50 ms later.
Some unimplemented features allow you to control the behavior when missing deadlines.
Jun
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Jun Sun
jsun> For many MIPS boards that start to use CONFIG_NEW_TIME_C, two jsun> rtc operations are implemented, rtc_get_time() and jsun> rtc_set_time().
jsun> It is possible to write a simple generic RTC driver that is jsun> based on these two ops and can do simple RTC read&write ops.
...
jsun> This is the idea behind the generic MIPS rtc driver. See the jsun> patch below.
...
jsun> Any comments?
Good idea. I hope cvs kernel import this patch.
I found two small things to fix. to_tm function sets 1..12 value in tm_mon field, so
1. in rtc_ioctl (case RTC_RD_TIME), subtracting 1 from rtc_tm.tm_mon is needed.
2. in rtc_proc_output, adding 1 to tm.tm_mon is not needed.
---
Atsushi Nemoto
Quoted 15 lines · Atsushi Nemoto
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines · Jun Sun
jsun> For many MIPS boards that start to use
CONFIG_NEW_TIME_C, two jsun> rtc operations are implemented,rtc_get_time()and jsun>rtc_set_time().
jsun> It is possible to write a simple generic RTC driver that is jsun> based on these two ops and can do simple RTC read&write ops.
...
jsun> This is the idea behind the generic MIPS rtc driver. See the jsun> patch below.
...
jsun> Any comments?Good idea. I hope cvs kernel import this patch.
Quoted 8 lines
I found two small things to fix.
to_tmfunction sets 1..12 value intm_monfield, so1. in
rtc_ioctl(caseRTC_RD_TIME), subtracting 1 from rtc_tm.tm_mon is needed.2. in
rtc_proc_output, adding 1 to tm.tm_mon is not needed.
Good eye for spotting this. :-)
It turned out that tm_mon in rtc_time struct really should start from 0 to 11 (by definition). So there is a bug in to_tm(). I sent a patch to Ralf and I think he applied already.
Jun