On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the RTC driver should be ok.
which breaks hwclock, not acceptable.
--
Ethan Benson
http://www.alaska.net/~erbenson/
On Wed, Jan 07, 2004 at 10:27:33PM -0900, Ethan Benson wrote:
On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the RTC driver should be ok.
which breaks hwclock, not acceptable.
On Thu, Jan 08, 2004 at 08:53:31AM -0700, Tom Rini wrote:
On Wed, Jan 07, 2004 at 10:27:33PM -0900, Ethan Benson wrote:
On Wed, Jan 07, 2004 at 03:47:44PM +0100, Sven Luther wrote:
The worse that can happen is the GENERIC_RTC driver not being
initialized because linux believes the
Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
the clock is set, but only _later_. This has as result that the clock is
wrong when it is the time for filesystem checks, and thus filesystems
are checked each time.
Your arch code should set an initial UTC time in
On Fri, Jan 09, 2004 at 08:53:07AM +1100, Benjamin Herrenschmidt wrote:
Anyway, on pegasos 2, i have the problem that CONFIG_RTC works fine, and
the clock is set, but only _later_. This has as result that the clock is
wrong when it is the time for filesystem checks, and thus filesystems
On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence of a pmac in the CONFIG_RTC code, and abort
if one is found ?
If so,
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence
On Wed, Jan 07, 2004 at 06:22:25PM +1100, Benjamin Herrenschmidt wrote:
BTW, i didn't manage to get the generic RTC code working on my pegasos,
and i am actually a bit pressed for time.
Do you think a workaround, for the debian powerpc packages, would be to
add a test for the presence
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the multiarch config (PREP/CHRP/PMAC)
2) The other failures in rtc_init return -EIO, not -ENODEV.
Well, in this case, -ENODEV makes more sense, though nothing really
cares except the kind of error message the
On Wed, 2004-01-07 at 20:53, Sven Luther wrote:
On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the multiarch config (PREP/CHRP/PMAC)
Ok. I suppose it doesn't make sense also to
So, would it be meaningfull to change all the others to NODEV too ?
You are beeing anal or what ? :)
Who cares about that legacy driver in 2.4 anyway :)
If you really want, I suppose the failure on request_region could
return -EBUSY, not sure about the best error to return from failures
on
On Wed, Jan 07, 2004 at 12:27:26PM +0100, Sven Luther wrote:
Mmm, notice that this is the rtc_init code, not the rtc ioctl's
themself. In my understanding this is launched when the kernel is
loaded, and is used to setup the rtc clock. If it fails, then no harm
should be done, since the
On Wed, Jan 07, 2004 at 07:30:06PM +1100, Benjamin Herrenschmidt wrote:
1) could a #ifdef __powerpc__ not be enough ?
No. _machine is only defined for the multiarch config (PREP/CHRP/PMAC)
Technically it's '0' on !CONFIG_ALL_PPC, but (for the sake of fullness)
I don't know if ppc64
On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 09:47:40AM -0700,
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or
On Mon, Dec 22, 2003 at 02:45:04PM +0100, Sven Luther wrote:
On Fri, Dec 19, 2003 at 09:28:00AM -0700, Tom Rini wrote:
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100,
On Mon, Dec 22, 2003 at 05:48:22PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
Also, the todc code knows about many RTC
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the rtc.h stuff, and seems to be a generic
legacy RTC chip or something. he one i have, builtin the VIA VT8231
southbridge is said
On Mon, Dec 22, 2003 at 09:33:15AM -0700, Tom Rini wrote:
On Mon, Dec 22, 2003 at 05:26:01PM +0100, Sven Luther wrote:
On Mon, Dec 22, 2003 at 09:10:42AM -0700, Tom Rini wrote:
Also, the todc code knows about many RTC chips, among them, the MC146818
seems to be the one used by the
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
4) Use CONFIG_GEN_RTC and be happy. What
On Tue, 2003-12-16 at 21:56, Sven Luther wrote:
Hello,
On my Pegasos/CHRP box, i noticed that not setting the CONFIG_RTC option
in the Character device part of the configuration (not to be confused with
the CONFIG_GENERIC_RTC and CONFIG_PPC_RTC options in the General setup
part) will cause
On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
CONFIG_RTC will definitely break a pmac
I think I heard something about clock/timer problems on PPC a long time ago,
but could never track down an issue. Wouldn't it be best to remove RTC on
PPC or document the problem with a
On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
CONFIG_RTC will definitely break a pmac
I think I heard something about clock/timer problems on PPC a long time ago,
but could never track down an issue. Wouldn't it be best to
On Wed, 17 Dec 2003, Sven Luther wrote:
On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
CONFIG_PPC_RTC/CONFIG_GENERIC_RTC is a different driver that provides
the /dev/rtc interface but relies on hooks provided by the platform
code for actually getting/setting the RTC
On Wed, Dec 17, 2003 at 05:24:54PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2003-12-16 at 21:56, Sven Luther wrote:
Hello,
On my Pegasos/CHRP box, i noticed that not setting the CONFIG_RTC option
in the Character device part of the configuration (not to be confused with
the
BTW, should this discussion not be moved to linuxppc mailing lists ?
On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
On Wednesday 17 Dec 2003 6:24 am, Benjamin Herrenschmidt wrote:
CONFIG_RTC will definitely break a
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM
On Wed, 17 Dec 2003, Segher Boessenkool wrote:
No, that's VIA as in Versatile Interface Adapter, not as in VIA
Technologies.
It used to be a separate chip in the old 68000 days, but now it's
integrated in
some Mac fabric (e.g. Mac I/O).
Actually, there is no RTC chip _at all_ in
No, that's VIA as in Versatile Interface Adapter, not as in VIA
Technologies.
It used to be a separate chip in the old 68000 days, but now it's
integrated in
some Mac fabric (e.g. Mac I/O).
Actually, there is no RTC chip _at all_ in NewWorld Macs. The PMU
itself keeps the time (from a
On Wed, Dec 17, 2003 at 10:51:39AM +0100, Sven Luther wrote:
BTW, should this discussion not be moved to linuxppc mailing lists ?
On Wed, Dec 17, 2003 at 06:27:37PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2003-12-17 at 18:17, Lee Braiden wrote:
On Wednesday 17 Dec 2003 6:24 am,
On Wed, Dec 17, 2003 at 05:24:54PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2003-12-16 at 21:56, Sven Luther wrote:
Hello,
On my Pegasos/CHRP box, i noticed that not setting the CONFIG_RTC option
in the Character device part of the configuration (not to be confused with
the
On Wed, Dec 17, 2003 at 06:10:52PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
4) Use CONFIG_GEN_RTC and be happy. What
On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
is that chrp_get_rtc_time is 'funky' and not quite right for anything
other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
looking at
Actually, there is no RTC chip _at all_ in NewWorld Macs. The PMU
itself keeps the time (from a 32768Hz clock).
So from a technical point of view, the PMU is the RTC chip, right?
Not really, it's a very different mechanism. But you could say it
is yeah, if you don't mind being sloppy ;-)
Hello,
On my Pegasos/CHRP box, i noticed that not setting the CONFIG_RTC option
in the Character device part of the configuration (not to be confused with
the CONFIG_GENERIC_RTC and CONFIG_PPC_RTC options in the General setup
part) will cause some strange delay when setting the hardware clock on
38 matches
Mail list logo
