[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200701091601.51830.david-b@pacbell.net>
Date: Tue, 9 Jan 2007 16:01:51 -0800
From: David Brownell <david-b@...bell.net>
To: Woody Suwalski <woodys@...dros.com>
Cc: Alessandro Zummo <alessandro.zummo@...ertech.it>,
rtc-linux@...glegroups.com,
Linux Kernel list <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>
Subject: Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver
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 ... <asm/rtc.h> seems to not
give equivalent functionality even on platforms which have it.
Looks to me like <asm-generic/rtc.h> is the right solution, though
that still implies arch-level support for <asm/mc146818rtc.h> 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 <asm-generic/rtc.h> 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.
> >>>
> <anderson@...sweng.com>
> 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
View attachment "rtc-arm.patch" of type "text/x-diff" (886 bytes)
View attachment "rtc-cmos-2.patch" of type "text/x-diff" (23292 bytes)
Powered by blists - more mailing lists