On Mon, Dec 22, 2003 at 02:45:04PM +0100, Sven Luther wrote: > 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.
I appologize since I ramble a bit too much. For 2.4, the best fix is (1) above. For 2.6 however, it should be possible to remove chrp_time.c and use todc_time.c instead (it is self-contained, wrt nvram read/write, iirc) and do some sub-casing to pick the right RTC chip code to use. For example on PReP we still case between the two different chips, and just call todc_init (iirc) with a different param. Or something along those lines. -- Tom Rini http://gate.crashing.org/~trini/
