Re: [RFC] generic MIPS RTC driver

Re: [RFC] generic MIPS RTC driver

[Geert Uytterhoeven]

On Sat, 10 Nov 2001, Jun Sun wrote:
> 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.

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 -- geert@linux-m68k.org

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/

Re: [RFC] generic MIPS RTC driver

[Maciej W. Rozycki]

On Sun, 11 Nov 2001, Geert Uytterhoeven wrote:

> > 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.
>
> 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.

 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: macro@ds2.pg.gda.pl, PGP key available        +


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [RFC] generic MIPS RTC driver

[Geert Uytterhoeven]

On Mon, 12 Nov 2001, Maciej W. Rozycki wrote:
> On Sun, 11 Nov 2001, Geert Uytterhoeven wrote:
> > > 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.
> >
> > 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.
>
>  Agreed, what's wrong with drivers/char/rtc.c?  It even works for the

It's for MC146818 RTCs only.

> 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.

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 -- geert@linux-m68k.org

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/

Re: [RFC] generic MIPS RTC driver

[Maciej W. Rozycki]

On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:

> >  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.

 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: macro@ds2.pg.gda.pl, PGP key available        +


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [RFC] generic MIPS RTC driver

[Pete Popov]

On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:
> On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:
>
> > >  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.
>
>  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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

Geert Uytterhoeven wrote:
>
> On Mon, 12 Nov 2001, Maciej W. Rozycki wrote:
> > On Sun, 11 Nov 2001, Geert Uytterhoeven wrote:
> > > > 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.
> > >
> > > 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.
> >
> >  Agreed, what's wrong with drivers/char/rtc.c?  It even works for the
>
> It's for MC146818 RTCs only.
>
> > 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.
>
> 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.
>

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/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

"Maciej W. Rozycki" wrote:
>
> On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:
>
> > >  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.
>
>  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.

> 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/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

Pete Popov wrote:
>
> On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:
> > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:
> >
> > > >  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.
> >
> >  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/

Re: [RFC] generic MIPS RTC driver

[Maciej W. Rozycki]

On Mon, 12 Nov 2001, Jun Sun wrote:

> 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.

 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.

> 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: macro@ds2.pg.gda.pl, PGP key available        +


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

Jun Sun wrote:
>
> Pete Popov wrote:
> >
> > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:
> > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:
> > >
> > > > >  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.
> > >
> > >  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.
>

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/

Re: [RFC] generic MIPS RTC driver

[Maciej W. Rozycki]

On Mon, 12 Nov 2001, Jun Sun wrote:

> >  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?

> > 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: macro@ds2.pg.gda.pl, PGP key available        +


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

"Maciej W. Rozycki" wrote:
>
> On Mon, 12 Nov 2001, Jun Sun wrote:
>
> > 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.
>
>  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.
>
> > 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.
>

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/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

"Maciej W. Rozycki" wrote:
>
> On Mon, 12 Nov 2001, Jun Sun wrote:
>
> > >  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/

Re: [RFC] generic MIPS RTC driver

[Geert Uytterhoeven]

On Mon, 12 Nov 2001, Jun Sun wrote:
> Geert Uytterhoeven wrote:
> > On Mon, 12 Nov 2001, Maciej W. Rozycki wrote:
> > >  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.
> >
>
> Geert, what is the abstraction they used?

At first sight, we only use get_rtc_time() and mach_hwclk().

> 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.

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 -- geert@linux-m68k.org

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/

Re: [RFC] generic MIPS RTC driver

[Roman Zippel]

Hi,

Geert Uytterhoeven wrote:

> > Geert, what is the abstraction they used?
>
> At first sight, we only use get_rtc_time() and mach_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/

Re: [RFC] generic MIPS RTC driver

[Tom Rini]

On Mon, Nov 12, 2001 at 10:56:44AM -0800, Jun Sun wrote:

> Jun Sun wrote:
> >
> > Pete Popov wrote:
> > >
> > > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote:
> > > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote:
> > > >
> > > > > >  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.
> > > >
> > > >  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.
> >
>
> 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.

Right.

> 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.

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.

> 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.

> 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.

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/

Re: [RFC] generic MIPS RTC driver

[Tom Rini]

On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote:
>
> Hi,
>
> Geert Uytterhoeven wrote:
>
> > > Geert, what is the abstraction they used?
> >
> > At first sight, we only use get_rtc_time() and mach_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.

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/

Re: [RFC] generic MIPS RTC driver

[Geert Uytterhoeven]

On Mon, 12 Nov 2001, Tom Rini wrote:
> On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote:
> > Geert Uytterhoeven wrote:
> > > > Geert, what is the abstraction they used?
> > >
> > > At first sight, we only use get_rtc_time() and mach_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.
>
> 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 -- geert@linux-m68k.org

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/

Re: [RFC] generic MIPS RTC driver

[Richard Zidlicky]

On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote:
> Hi,
>
> Geert Uytterhoeven wrote:
>
> > > Geert, what is the abstraction they used?
> >
> > At first sight, we only use get_rtc_time() and mach_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.

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/

Re: [RFC] generic MIPS RTC driver

[Tom Rini]

On Tue, Nov 13, 2001 at 07:20:51AM +0100, Geert Uytterhoeven wrote:
> On Mon, 12 Nov 2001, Tom Rini wrote:
> > On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote:
> > > Geert Uytterhoeven wrote:
> > > > > Geert, what is the abstraction they used?
> > > >
> > > > At first sight, we only use get_rtc_time() and mach_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.
> >
> > 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/

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/

Re: [RFC] generic MIPS RTC driver

[Geert Uytterhoeven]

On Tue, 13 Nov 2001, Tom Rini wrote:
> On Tue, Nov 13, 2001 at 07:20:51AM +0100, Geert Uytterhoeven wrote:
> > On Mon, 12 Nov 2001, Tom Rini wrote:
> > > On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote:
> > > > Geert Uytterhoeven wrote:
> > > > > > Geert, what is the abstraction they used?
> > > > >
> > > > > At first sight, we only use get_rtc_time() and mach_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.
> > >
> > > 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/
>
> 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 -- geert@linux-m68k.org

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/

Re: [RFC] generic MIPS RTC driver

[Roman Zippel]

Hi,

On Tue, 13 Nov 2001, Tom Rini wrote:

> > http://linux-m68k-cvs.apia.dhs.org/
>
> 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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [RFC] generic MIPS RTC driver

[Roman Zippel]

Hi,

On Tue, 13 Nov 2001, Richard Zidlicky wrote:

> 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/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

Richard Zidlicky wrote:

> 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/

Re: [RFC] generic MIPS RTC driver

[Richard Zidlicky]

On Tue, Nov 13, 2001 at 04:32:42PM +0100, Roman Zippel wrote:
> Hi,
>
> On Tue, 13 Nov 2001, Richard Zidlicky wrote:
>
> > 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/

Re: [RFC] generic MIPS RTC driver

[Richard Zidlicky]

On Tue, Nov 13, 2001 at 09:58:45AM -0800, Jun Sun wrote:
> Richard Zidlicky wrote:
>
> > 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.

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/

Re: [RFC] generic MIPS RTC driver

[Jun Sun]

Richard Zidlicky wrote:
>
> On Tue, Nov 13, 2001 at 09:58:45AM -0800, Jun Sun wrote:
> > Richard Zidlicky wrote:
> >
> > > 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.
>
> 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?

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/