Changing the current RTC device interface

Changing the current RTC device interface

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

Hi!

I have a board with multiple RTC chips (Built-in RTC in the processor +
external battery backed RTC).

There are pros and cons to each RTC chip. The CPU's RTC doesn't have a
battery, but have high resolution timing + multiple rtc counters/interrupts,
so it is especially suited for apps that want to use /dev/rtc for high
resolution timing.

On the other hand the external RTC chip can keep time, but its timing is
crap (1hz to 8khz in steps of powers of two), so you don't want to use that
for timing.

At the moment, Linux only allows for a single RTC device, so one can't reap
the benefits of both chips mentioned above.

How about we get a major number assigned to rtc subsystem and then allows
for multiple rtc devices.

The same argument goes for the non-volatile ram found on RTC chips, so we
actually need to change the entire RTC interface so that we can throw away
/dev/nvram

Any objections / suggestions / comments about things that's wrong/right
about the current RTC implementation?

-- 

Regards
 Abraham

Never leave anything to chance; make sure all your crimes are premeditated.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Changing the current RTC device interface

[Alan Cox]

On Tue, 2002-05-28 at 15:24, Abraham vd Merwe wrote:
> I have a board with multiple RTC chips (Built-in RTC in the processor +
> external battery backed RTC).
> 
> There are pros and cons to each RTC chip. The CPU's RTC doesn't have a
> battery, but have high resolution timing + multiple rtc counters/interrupts,
> so it is especially suited for apps that want to use /dev/rtc for high
> resolution timing.
> 
> On the other hand the external RTC chip can keep time, but its timing is
> crap (1hz to 8khz in steps of powers of two), so you don't want to use that
> for timing.
> 
> At the moment, Linux only allows for a single RTC device, so one can't reap
> the benefits of both chips mentioned above.
> 
> How about we get a major number assigned to rtc subsystem and then allows
> for multiple rtc devices.

I think you should wait until 2.5 has reached the point we have a
finished devicefs and 32bit dev_t. Basically we don't have enough device
numbering left for such trivialities right now.

Re: Changing the current RTC device interface

[DervishD]

    Hi Abraham :)

>>Any objections / suggestions / comments about things that's wrong/right
>>about the current RTC implementation?

    I think that, today at least, the nvram device is almost useless,
since only a few bytes are common to all BIOS vendors. The best
solution I can think about is just the same you propose: two devices,
one for the processor builtin RTC (the TSC counter?) and another for
the usual RTC on the motherboard.

    The only ugly thing I see is the NVRam driver, which I consider
useless these days.

    Raúl

Re: Changing the current RTC device interface

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

Hi DervishD!

>     The only ugly thing I see is the NVRam driver, which I consider
> useless these days.

It's not always useless. I'm pretty sure nobody every use it for PCs, but in
my case, I'm working on some embedded boards where 56 bytes of nvram is
quite useful for storing serial numbers, etc.

-- 

Regards
 Abraham

My problem lies in reconciling my gross habits with my net income.
		-- Errol Flynn

Any man who has $10,000 left when he dies is a failure.
		-- Errol Flynn

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Aintree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]