[asterisk-dev] Re: ztdummy question

[Tzafrir Cohen]

On Sat, Jan 21, 2006 at 02:34:48PM +0000, Tony Mountifield wrote:
> In article <20060121123848.GF16880 at xorcom.com>,
> Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
> > On Sat, Jan 21, 2006 at 10:14:44AM +0000, Tony Mountifield wrote:
> > > In article <43D14D89.8010506 at kinex.net>, Sean Cook <scook at kinex.net> wrote:
> > > > 
> > > > with the changes to the ztdummy to rely on rtc vs jiffies, I am now
> > > > forced to increase the interrupt frequency time by roughly 10x the
> > > > frequency recommended for the SMP processing systems.
> > > > 
> > > > Is this wise?  Or would it be better to not assume that the CONFIG_HZ ==
> > > > 1000 and base the calculation on what ever HZ is set to?
> > > 
> > > You should make sure that USE_RTC is defined, and then you WON'T depend
> > > on the value of HZ in the kernel, because the interrupts will be generated
> > > by the RTC chip and not hooked into the kernel jiffy clock.
> > 
> > What reason is there not to set USE_RTC, assuming my kernel provides the
> > necessary timer interface?
> 
> In my opinion, no reason at all. The only reason USE_RTC is inside a #if 0
> for 2.6 kernels before 2.6.13 is because when the patch was originally
> committed, the committer updated ztdummy.c but forgot to do ztdummy.h.
> (I don't know why - they were both in the patch file I submitted).  This
> resulted in some vocal complaints of compilation errors, and the #if 0 was
> put in as a knee-jerk fix before understanding the true reasons for the
> errors.  See the history on bug #4301.

The following is from zaptel 1.2.1, I believe:

#if defined(__i386__)
#if LINUX_VERSION_CODE >= VERSION_CODE(2,6,13)
#define USE_RTC
#else
#if 0
#define USE_RTC
#endif
#endif
#endif

Just for the kernels that happen to be install on my system:

2.4.27-2-686 and 2.6.8-2-686 are default Debian Sarge kernels. 2.6.10
and 2.6.150rc5-swsusp were built by me after much mocking with make
menuconfig.

tzafrir at boomtime:~/Proj/Asterisk/asterisk$ grep RTC /boot/config* /usr/src/kernel-headers-2.6.8-2-686/.config
/boot/config-2.4.27-2-686:# CONFIG_APM_RTC_IS_GMT is not set
/boot/config-2.4.27-2-686:CONFIG_RTC=m
/boot/config-2.6.10:CONFIG_RTC=m
/boot/config-2.6.10:# CONFIG_GEN_RTC is not set
/boot/config-2.6.10:CONFIG_SENSORS_RTC8564=m
/boot/config-2.6.10:CONFIG_SND_RTCTIMER=m
/boot/config-2.6.15-rc5-swsusp:CONFIG_RTC=m
/boot/config-2.6.15-rc5-swsusp:CONFIG_GEN_RTC=m
/boot/config-2.6.15-rc5-swsusp:# CONFIG_GEN_RTC_X is not set
/boot/config-2.6.15-rc5-swsusp:CONFIG_SENSORS_RTC8564=m
/boot/config-2.6.15-rc5-swsusp:CONFIG_RTC_X1205_I2C=m
/boot/config-2.6.15-rc5-swsusp:CONFIG_SND_RTCTIMER=m
/boot/config-2.6.15-rc5-swsusp:CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
/usr/src/kernel-headers-2.6.8-2-686/.config:# CONFIG_APM_RTC_IS_GMT is not set
/usr/src/kernel-headers-2.6.8-2-686/.config:CONFIG_RTC=m
/usr/src/kernel-headers-2.6.8-2-686/.config:CONFIG_GEN_RTC=m
/usr/src/kernel-headers-2.6.8-2-686/.config:CONFIG_GEN_RTC_X=y
/usr/src/kernel-headers-2.6.8-2-686/.config:# CONFIG_HPET_RTC_IRQ is not set
/usr/src/kernel-headers-2.6.8-2-686/.config:CONFIG_SENSORS_RTC8564=m
/usr/src/kernel-headers-2.6.8-2-686/.config:CONFIG_SND_RTCTIMER=m

> 
> It's a great pity the #if 0 is still there as the default in zaptel-1.2,
> but I got fed up campaigning for it.

So, should the above condition be "kernel version >= 2.6.13 [or
maybe a lower version] && CONFIG_RTC being set?

I figure that the code there is 2.6-specific anyway.

> 
> > Is there a better check for the timer interface at CPP time other than
> > the kernel version? Any specific CONFIG_ macro to check for? CONFIG_RTC?
> > CONFIG_GEN_RTC? 
> 
> I'm not sure whether the CONFIG macros are available to be tested against
> at the time of compiling ztdummy. USE_RTC is only compatible with 
> CONFIG_RTC=y or CONFIG_RTC=m, not with CONFIG_GEN_RTC.
> 
> But CONFIG_GEN_RTC is really intended for non-PC architectures.
> 
> > Is it possible that an x86 PC will not support RTC even if there is
> > kernel-level support?
> > 
> > What about other architectures? amd64 comes to mind as an archtecture
> > that works with a somewhat similar hardware.
> 
> I don't know, I'm afraid. I suppose an embedded x86 non-pc might not
> have the 146818 RTC chip. I believe any machine designed as a standard
> PC architecture would have it.

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com