Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?

[Sven Luther]

On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
>
> On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
> > On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> > >
> > > On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> > > >
> > > > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > > > 4) Use CONFIG_GEN_RTC and be happy.  What _might_ be happening right now
> > > > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > > > other than an IBM OpenFirmeware'd CHRP box.  What I would suggest is
> > > > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> > > >
> > > > Ok, thanks, i will look into it.
> > > >
> > > > But then, remember, this is for the debian powerpc kernel, and has to be
> > > > 2.4.x still for now.
> > >
> > > Yes.  The code in <asm-generic/rtc.h> is taken right from
> > > drivers/char/rtc.c.  It just didn't get sent to 2.4 for some reason.
> >
> > Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
> > set_rtc_time function.
>
> Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)

Ok.

> > BTW, what exactly should i do in 'chrp_get_rtc_time' and
> > 'chrp_set_rtc_time' ? Just replace the existing code, or make a new
> > function, and set it depending on machine type who needs it in
> > chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
> > have to set ppc_md.set_rtc_time accordyingly.
>
> My preferance would be to replace, and then see if it breaks some other
> chrp machines (it really shouldn't).

Ok, fine, altough i don't have an idea about the other chrp machine
types out there. From what i know from Geert, generic RTC is already not working
for its box anyway.

> Something that just dawned on me again (sorry) is that I've really really
> intended to try and kill both prep_time.c and chrp_time.c (since both of
> those machine subtypes have PC-style RTC chips) and make them use
> todc_time.c (see arch/ppc/kernel/todc_time.c).  I've got patches to do
> half of this, against 2.6 (which was a trivial forward port of older
> 2.4-based patches I had, there is nothing 2.6-specific about these
> patches).  You would want to look at:
> 006-redo_inb_inw_inl_outb_outw_outl.patch
> 007-make_out_8_and_friends_synchronous.patch
> 008-todc_warning.patch
> 009-prep_time_death-GNU.patch
> from http://stop.crashing.org:16080/~trini/

Mmm, i am somewhat confused now on what to do.

If i understood things tight, you either want to :

  1) replace ppc.md chrp time stuff with similar code than what
  asm-generic/rtc.h is doing.

  2) use todc.h for all of prep/chrp.

In the first case, i guess that is easy, and may break some chrp boxes
not using a compatible clock, which may or may not exist.

In the second case, well, the todc code makes use of nvram_write, which
unless i am wrong, is not defined on chrp. the RTC code uses CMOS_WRITE,
so maybe i should define a chrp_write wrapping this one.

Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said to be called VT82887, altough i have no docs of
those, but the header files found in 2.6 concord. But i seem to have
some additional DATE_ALARM, MONTH_ALARM and CENTURY_FIELD registers not
found int the MC146818 header file.

So, what did you have in mind for this.

Friendly,

Sven Luther

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