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
