On Tuesday 09 January 2007 8:37 am, Woody Suwalski wrote: > As to the patch: applied to 2.6.20-rc4, both on PC and ARM, commented > out "EXPERIMENTAL"... > > To build your new patch for ARM I have modified the line "depends on > RTC_CLASS && (X86_PC || ACPI || ARM)"... > > On Netwinder ARM - can not build (see: rtc_build.log) Heh, so it's a good thing I disabled the build there. :) > OK, changed the include/asm/rtc.h to look like i386 == include > asm-generic/rtc.h In drivers/rtc/rtc-cmos.c I hope ... seems to not give equivalent functionality even on platforms which have it. Looks to me like is the right solution, though that still implies arch-level support for which does not exist on all platforms. So the attached version of the rtc-cmos patch uses asm-generic and also adds Kconfig dependencies for architectures with usable versions of that header. Of course, the "right" answer is to make this be like any other driver and allow the registers to go anywhere in the address space, not hard-wiring them to a platform-specific I/O space address. That is, CMOS_READ/CMOS_WRITE are legacy baggage. But that's not an issue to be addressed by this particular patch. > Still does not build - see rtc_build2.log > > Could you please check what other defs are missing on ARM? I'm not sure what you changed. I updated the rtc-cmos patch to use directly, then did an ARM build which configured that driver as a module. No compile-time problems. (I think you changed the wrong file...) But at link time I ran into the problem that arm/kernel/time.c defines "rtc_lock" but only exports it to an obsolete SA1100 driver. See attached "rtc-arm.patch". But static linking was no problem ... of course, I didn't add any code to define the platform_device (with or without the platform_data teling about extra registers) and couldn't test anything other than the build. > >>> > > As for the RTC patch, it does work on the shark, and is needed. > <<< > > So is there a reason to have RTC build blocked on all ARM? The original reason was that it's not known to work. Given the attached patches, that issue is resolved at least from the build perspective. - Dave