Re: [rtc-linux] Re: [PATCH v3 03/11] rtc: Add MPC5121 Real time clock driver
On Tue, 9 Feb 2010 19:39:35 -0700 Grant Likely grant.lik...@secretlab.ca wrote: Acked-by: Grant Likely grant.lik...@secretlab.ca Alessandro, do you want me to carry this one in my powerpc tree along with the rest of the 5121 patches, or do you want to carry it? There aren't any commit ordering issues on this one. Yes please. thanks. Acked-by: Alessandro Zummo a.zu...@towertech.it -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH 05/11] rtc: Add MPC5121 Real time clock driver
mpc5121_rtc_driver = {
+ .owner = THIS_MODULE,
+ .name = mpc5121-rtc,
+ .match_table = mpc5121_rtc_match,
+ .probe = mpc5121_rtc_probe,
+ .remove = mpc5121_rtc_remove,
+};
+
+static int __init mpc5121_rtc_init(void)
+{
+ return of_register_platform_driver(mpc5121_rtc_driver);
+}
+
+static void __exit mpc5121_rtc_exit(void)
+{
+ of_unregister_platform_driver(mpc5121_rtc_driver);
+}
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(John Rigby jri...@freescale.com);
+
+module_init(mpc5121_rtc_init);
+module_exit(mpc5121_rtc_exit);
--
1.5.6.3
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 10/12] mpc5121: Add MPC5121 Real time clock driver.
On Fri, 8 May 2009 09:53:20 -0600 Grant Likely grant.lik...@secretlab.ca wrote: That is fine by me, but since it is known that it will eventually support both, I'd like it to be renamed to 5xxx before it is merged to avoid a later rename patch. sorry, forget my last email, I misread the codes. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 10/12] mpc5121: Add MPC5121 Real time clock driver.
On Fri, 8 May 2009 09:53:20 -0600 Grant Likely grant.lik...@secretlab.ca wrote: That is fine by me, but since it is known that it will eventually support both, I'd like it to be renamed to 5xxx before it is merged to avoid a later rename patch. or 52xx ? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Tue, 10 Mar 2009 10:21:14 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Alessandro prefers not to have generic RTC drivers on top of some other abstraction, but wants platform/chip-specific drivers under drivers/rtc/ instead. The goal is to convert all RTC drivers buried in platform code to separate RTC drivers. (Alessandro, please correct me if I'm wrong) yes, that's my dream :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Mon, 9 Mar 2009 14:26:23 +0100
Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote:
Hi,
just a few notes:
+
+static int ps3_get_time(struct device *dev, struct rtc_time *tm)
+{
+ to_tm(read_rtc() + ps3_os_area_get_rtc_diff(), tm);
+ tm-tm_year -= 1900;
+ tm-tm_mon -= 1;
+ return 0;
+}
this should be return rtc_valid_tm() .
can't you use functions from rtc-lib.c instead of
that to_tm ?
+
+MODULE_AUTHOR(Sony Corporation);
real name, if possible and a contact address
here . Just in case I need someone to bother :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH 0/7] Generic RTC class driver
On Mon, 9 Mar 2009 14:26:16 +0100 Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Hi Alessandro et al, These patches are relative to the rtc-parisc branch of Kyle's PA-RISC git repository, which already contains some cleanups for the rtc-parisc driver by Dann, which already have been ack'ed by Alessandro: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=shortlog;h=rtc-parisc Paul: Feel free to add your SuperH support. I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as he already has the preceding patches? Can I have your acks, please? Here's mine. Thanks for your efforts . Acked-by: Alessandro Zummo a.zu...@towertech.it btw I'll pretend I had never seen this patch if asked in court :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH 7/7] powerpc/ps3: Add rtc-ps3
On Mon, 9 Mar 2009 11:04:17 -0700 Geoff Levand geoffrey.lev...@am.sony.com wrote: Hi, On 03/09/2009 07:12 AM, Alessandro Zummo wrote: On Mon, 9 Mar 2009 14:26:23 +0100 Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: + +MODULE_AUTHOR(Sony Corporation); real name, if possible and a contact address here . Just in case I need someone to bother :) Please look at the MAINTAINERS file, that will give the contact for PS3. It is much easier to maintain a single place for the contact than many spread throughout the kernel sources. Having it in MODULE_AUTHOR allow my scripts to automatically send an email when appropriate. MAINTAINERS lists the files with an arbitrary driver title so that the search must be made by an human and there's no field that links a person to a specific .c . so every time I want to address someone I need to check MODULE_AUTHOR, the git log and the MAINTAINERS file. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 4 Mar 2009 09:26:29 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Thanks Paul, I wasn't aware of that thread! Yes, this is almost the same. The only part I don't agree with is the move of the creation of the platform device from arch-specific code to rtc-firmware.c, as this makes autoloading the driver more difficult. and it's also against a proper implementation of the device/driver model. Seems like everybody but the RTC maintainer has an interest in having an RTC class driver on top of [gs]et_rtc_time()... ;-) That's because everyone is lazy :) Seriously, if you want to handle it in the way we wrote in the previous emails, it's ok for me. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Tue, 3 Mar 2009 11:41:23 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: rtc-generic is already in the kernel, it's just called rtc-parisc ;-) Really? I never saw it :) But I'd strongly suggest to plan and execute a conversion process. So would you accept a patch series that: 1. Adds the missing module aliases to rtc-parisc (which is a bugfix), 2. Moves the platform device creation out of rtc-ppc and into arch-specific code (which is also a bugfix), 3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup), 4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing [sg]et_rtc_time() users): a. without introducing ARCH_HAS_GENERIC_RTC, b. with a big fat warning in the Kconfig comment not relaxing the dependencies, as it's supposed to go away. 4. Converts the PS3 RTC support into a separate driver, called rtc-ps3 (as a bonus ;-) ? If yes, I'll cook it up. Other RTC platform support can be converted into separate drivers later. Seems reasonable. But please add a list of users of rtc-generic and information about their respective rtc hardware along with some general planning about which future driver would cover which users. And let's hope this is a beginning :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 2 Mar 2009 10:54:14 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Indeed. You can have a working RTC class driver for lots of hardware by just writing ca. 100 lines of code on top of the generic framework. That's true, but we would then have two generic frameworks. And one of them will have its code scattered all around the kernel. So you either use the old rtc framework, which is perfectly functional, or you move to the new rtc lass and write the drivers. Layering a generic framework over another generic framework is quite a nonsense . -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 2 Mar 2009 11:28:01 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: So I can solve my problem (autoloading the RTC driver on PS3 by udev) by converting the old genrtc driver into a platform device driver and creating platform devices where appropriate. yes. btw, if you are building a kernel specific for the PS3, I would compile the rtc driver statically, otherwise it won't be available early on boot. However, this doesn't solve the distro's problem: as the old RTC framework depends on RTC_LIB=n, you cannot have both old and new RTC drivers in your (single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c: Fedora had to support machines with both old and new RTC drivers. As all of the old drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, this was very easy. ok, generic kernel. you will have to load the modules on initrd. no, sadly you can't have both of them. you might stick with the old interface or convert them all. Hence it's all or nothing, and we have to convert all of them. drivers/rtc/rtc-generic.c would allow to have a working system without old RTC drivers, until all low-level code has been converted to individual RTC drivers. I know but I have enough experience to foresee that once a generic over generic framework is in place it's very hard to get rid of it because people will have no incentives. If you really need rtc-generic you can keep using it even if it's not in the kernel, distributions often have their specific set of kernel patches. But I'd strongly suggest to plan and execute a conversion process. Layering a generic framework over another generic framework is quite a nonsense . IMHO these two generic frameworks are quite different: [sg]et_rtc_time() abstracts the low-level RTC hardware interface, while RTC class handles the interaction with userspace. When I wrote it my intention was to make it as an abstraction _between_ the userspace and the hardware according to the platform/device model. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Fri, 27 Feb 2009 17:17:36 + (GMT) Maciej W. Rozycki ma...@linux-mips.org wrote: I posted patches to support it last year -- from your answer I infer they were not applied in the end. I'll see if I can try to refresh them and push again next time I'll be upgrading my kernel. they were almost ok but there are still a few things that I need to check before incorporating them. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 25 Feb 2009 11:00:13 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: I didn't know NTP was broken with RTC class drivers? So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for now? ;-) broken here means that the kernel won't save the time to the hardware rtc every 11 minutes as it used to do. normal NTP operations are unaffected. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Tue, 24 Feb 2009 18:56:03 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: On Mon, 23 I'd start writing a working driver and then see how we should eventually adapt the rtc subsystem to cope with your needs. OK, so here's a first example: rtc-ps3. Note that this single patch adds 100+ lines of code, while my previous patch series removed 500+ lines of code, while solving the autoloading problem for several ppc and m68k platforms. This patch has a much cleaner approach, imho. Converting all (ca. 20?) ppc and m68k RTC support code into individual RTC class drivers would add ca. 100+ lines of code for each individual driver. How different are all of those boards? It's simply a matter of parameters and offsets? can we group them somehow? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 25 Feb 2009 06:35:27 +0900 David Woodhouse dw...@infradead.org wrote: So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k], mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all RTC code out of arch/ into seperate drivers under drivers/rtc/ instead? That's the ideal... although did we get NTP sync working again yet? not yet. we're close but I've been very busy :( -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Mon, 23 Feb 2009 13:34:49 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Hello, my opinion on this kind of stuff is that I want to avoid the layering of implementations under the rtc subsystem. I'd rather prefer that each rtc device had its own driver. I've made error in the past, by accepting such kind of drivers, and would like to avoid that it happens again. So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k], mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all RTC code out of arch/ into seperate drivers under drivers/rtc/ instead? not all at once :) I'd start writing a working driver and then see how we should eventually adapt the rtc subsystem to cope with your needs. What about ppc_md.get_boot_time() [ppc]? Please note that the functions above may also be used for very early clock setting (e.g. time_init()) and in read_persistent_clock(). How should we handle these? read_persistent_clock is something that should be reconsidered as well along with all the ntp stuff. Even on x86 there seems to be way too much RTC logic in arch/x86/kernel/rtc.c (e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmos.c through the inline function __get_rtc_time() in include/asm-generic/rtc.h (clever, hardware-specific stuff in asm-generic ;-) yep, I know :( that hardcoded rtc stuff seems to be everywhere! -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] [PATCH/RFC 0/5] Generic RTC class driver
On Fri, 20 Feb 2009 16:46:44 +0100 Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Fortunately there already exists a generic RTC class driver: rtc-parisc. Despite it's name, it's platform-independent, as it's build on top of the RTC abstraction used by genrtc. This patch series - adds a missing module alias to rtc-parisc, - renames rtc-parisc to rtc-generic, - converts the architectures that currently have CONFIG_GEN_RTC enabled in their defconfig (m68k, parisc, powerpc) to rtc-generic, - removes the obsolete rtc-ppc driver, - removes the old genrtc driver. Note that genrtc may be used on other archictectures as well: at least alpha has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa). Furthermore genrtc and rtc-generic are not 100% userspace compatible: - /dev/rtc provided by genrtc uses a misc character device (10:135), - /dev/rtc provided by rtc-generic uses a dynamic character device. Hello, my opinion on this kind of stuff is that I want to avoid the layering of implementations under the rtc subsystem. I'd rather prefer that each rtc device had its own driver. I've made error in the past, by accepting such kind of drivers, and would like to avoid that it happens again. Regarding the user space, the assumption that a device has a fixed major:minor number should be dropped as well. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [RFC PATCH] rtc: add rtc_systohc for ntp use
On Tue, 11 Nov 2008 14:10:39 + David Woodhouse [EMAIL PROTECTED] wrote: You might do better to open the device once and keep it open, rather than taking the mutex and opening it again _during_ each call? You're going to be perturbing the timing by doing that. If you keep it open no other in-kernel user would be able to use it. I believe you were also concerned that some device wouldn't want the behaviour given by the existing sync_cmos_clock() function and workqueue stuff in kernel/ntp.c, where we update the clock precisely half-way through the second? We should probably rip that code out of ntp.c (or just disable it ifdef CONFIG_RTC_CLASS), and provide our own version of notify_cmos_timer(). The workqueue stuff to trigger at half-past the second could be kept as a library function which most RTC devices would use, but they'd have the option to use their own instead. I'll give it a look. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH] rtc: add rtc_systohc for ntp use
Adds in-kernel hctosys functionality that can
be used by ntp sync code.
This is an RFC and has not been tested, I just want
to check if something similar could solve the problems
of those who want the NTP sync mode.
Signed-off-by: Alessandro Zummo [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Cc: David Woodhouse [EMAIL PROTECTED]
---
drivers/rtc/Kconfig | 19 ++-
drivers/rtc/Makefile |1 +
drivers/rtc/systohc.c | 35 +++
3 files changed, 54 insertions(+), 1 deletions(-)
create mode 100644 drivers/rtc/systohc.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8abbb20..1ff9427 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,7 +30,7 @@ config RTC_HCTOSYS
unnecessary fsck runs at boot time, and to network better.
config RTC_HCTOSYS_DEVICE
- string RTC used to set the system time
+ string RTC used to set the system time on startup and resume
depends on RTC_HCTOSYS = y
default rtc0
help
@@ -52,6 +52,23 @@ config RTC_HCTOSYS_DEVICE
sleep states. Do not specify an RTC here unless it stays powered
during all this system's supported sleep states.
+config RTC_SYSTOHC
+ bool Set RTC from system time in NTP sync mode
+ depends on RTC_CLASS = y
+ default y
+ help
+ If you say yes here, the system time (wall clock) will be written
+ to the hardware clock every 11 minutes, if the kernel is in NTP
+ mode and your platforms supports it.
+
+config RTC_SYSTOHC_DEVICE
+ string RTC used to save the system time in NTP sync mode
+ depends on RTC_SYSTOHC = y
+ default rtc0
+ help
+ The RTC device that will get written with the system time
+ in NTP mode.
+
config RTC_DEBUG
bool RTC debug support
depends on RTC_CLASS = y
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index e9e8474..6d1c519 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -8,6 +8,7 @@ endif
obj-$(CONFIG_RTC_LIB) += rtc-lib.o
obj-$(CONFIG_RTC_HCTOSYS) += hctosys.o
+obj-$(CONFIG_RTC_SYSTOHC) += systohc.o
obj-$(CONFIG_RTC_CLASS)+= rtc-core.o
rtc-core-y := class.o interface.o
diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
new file mode 100644
index 000..41ec77b
--- /dev/null
+++ b/drivers/rtc/systohc.c
@@ -0,0 +1,35 @@
+/*
+ * RTC subsystem, systohc for ntp use
+ *
+ * Copyright (C) 2008 Tower Technologies
+ * Author: Alessandro Zummo [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/rtc.h
+
+static int rtc_systohc(struct rtc_time *tm)
+{
+ int err;
+ struct rtc_time tm;
+ struct rtc_device *rtc = rtc_class_open(CONFIG_RTC_SYSTOHC_DEVICE);
+
+ if (rtc == NULL) {
+ printk(%s: unable to open rtc device (%s)\n,
+ __FILE__, CONFIG_RTC_SYSTOHC_DEVICE);
+ return -ENODEV;
+ }
+
+ err = rtc_set_time(rtc, tm);
+ if (err != 0)
+ dev_err(rtc-dev.parent,
+ systohc: unable to set the hardware clock\n);
+
+ rtc_class_close(rtc);
+
+ return err;
+}
+EXPORT_SYMBOL(rtc_systohc);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH] rtc: add rtc_systohc for ntp use
On Mon, 10 Nov 2008 14:57:28 -0800 David Brownell [EMAIL PROTECTED] wrote: Yeah, we should have one of these. :) :) great! now let's see if we can get others to agree! A better default might be to update all the RTCs on the system. I'm thinking of my trusty test-case here: rtc0 is highly functional (including wake from RTC alarm) but not battery backed, while rtc1 is battery backed but only tracks time. NTP really needs to update both of them ... rtc0 since that's what's used most of the time, and also rtc1 since that's what actually *stores* the time during power off cycles. well, let's start with one... we all lived with one rtc until a couple of year ago :) +static int rtc_systohc(struct rtc_time *tm) I think static will lose, especially since ... wooops! -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rtc-ppc
On Wed, 05 Nov 2008 23:18:46 +0100 David Woodhouse [EMAIL PROTECTED] wrote: It would be possible, yes -- but it would be better to have the various PPC platforms just register RTC-class devices _directly_, and ditch the RTC bits from ppc_md altogether. That would be real fine :) I think we're waiting until the RTC class works with NTP before we can contemplate that, though. That will be a long wait, I don't think anyone volunteered for the ntp code. I've been told some platforms are already using the class. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: rtc-ppc
On Thu, 6 Nov 2008 10:08:25 +1100 David Gibson [EMAIL PROTECTED] wrote: I think we're waiting until the RTC class works with NTP before we can contemplate that, though. Yeah, I tried writing some ppc_md hooks which backended onto the rtc class drivers as an interim measure, but the hooks are called from places the rtc class stuff can't safely be called (too early, IIRC, but it's a while since I checked). I think the rtc drivers are too heterogeneous to have a valid ntp strategy. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] rtc-ds1374: Rename device to just ds1374
From: Jean Delvare [EMAIL PROTECTED]
Change the name of the device from rtc-ds1374 to just ds1374, to
match what all other RTC drivers do. I seem to remember that this name
was chosen to avoid possible confusion with an older ds1374 driver,
but that driver was removed 3 months ago.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Signed-off-by: Alessandro Zummo [EMAIL PROTECTED]
---
Patch already sent on:
* 2008-04-30
arch/powerpc/sysdev/fsl_soc.c |2 +-
drivers/of/of_i2c.c |1 -
drivers/rtc/rtc-ds1374.c |2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.26-rc0.orig/arch/powerpc/sysdev/fsl_soc.c 2008-04-29
22:55:32.0 +0200
+++ linux-2.6.26-rc0/arch/powerpc/sysdev/fsl_soc.c 2008-04-30
08:32:43.0 +0200
@@ -432,7 +432,7 @@ static struct i2c_driver_device i2c_devi
{dallas,ds1339, ds1339},
{dallas,ds1340, ds1340},
{stm,m41t00, m41t00},
- {dallas,ds1374, rtc-ds1374},
+ {dallas,ds1374, ds1374},
};
static int __init of_find_i2c_driver(struct device_node *node,
--- linux-2.6.26-rc0.orig/drivers/of/of_i2c.c 2008-04-29 07:41:15.0
+0200
+++ linux-2.6.26-rc0/drivers/of/of_i2c.c2008-04-30 08:32:38.0
+0200
@@ -21,7 +21,6 @@ struct i2c_driver_device {
};
static struct i2c_driver_device i2c_devices[] = {
- { dallas,ds1374, rtc-ds1374 },
};
static int of_find_i2c_driver(struct device_node *node,
--- linux-2.6.26-rc0.orig/drivers/rtc/rtc-ds1374.c 2008-04-29
23:07:07.0 +0200
+++ linux-2.6.26-rc0/drivers/rtc/rtc-ds1374.c 2008-04-30 08:32:33.0
+0200
@@ -42,7 +42,7 @@
#define DS1374_REG_TCR 0x09 /* Trickle Charge */
static const struct i2c_device_id ds1374_id[] = {
- { rtc-ds1374, 0 },
+ { ds1374, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ds1374_id);
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] state of GEN_RTC vs rtc subsystem
On Wed, 20 Feb 2008 10:11:23 -0600 Kumar Gala [EMAIL PROTECTED] wrote: Is the functionality provided by drivers/char/gen_rtc.c completely handled by the rtc subsystem in drivers/rtc? I ask for two reasons: 1. should we make it mutually exclusive in Kconfig 2. I've enabled both and get (we'll my defconfig did): They shouldn't be enabled at once. I think a patch for Kconfig has been recently submitted to give a warning in such a case. rtc-cmos should be able to handle the vast majority of x86 rtcs out there. The only real open issue is related to the ntp synchronization mode and will be solved only when we can get rid of it :) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: state of GEN_RTC vs rtc subsystem
On Wed, 20 Feb 2008 15:37:28 -0500 woodys [EMAIL PROTECTED] wrote: On ARM genrtc has been arbitrary disabled in Kconfig circa 2.6.19 and the change to rtc_cmos it is not 100% transparent (ARM Netwinder, Debian). If I want to use a current (Etch) hwclock binary - I need genrtc with /dev/rtc at 10,135, however new rtc_cmos creates /dev/rtc0 at 254,0. As a result on new kernels hwclock claims that it is not able to access hardware. However upgrading the util-linux package will (sometime in the unstable future) solve it, so it is not completely broken... Still, at the moment - genrtc seems to be a better solution... Strange that it has been disabled, I used to keep an eye to avoid touching anything outside of drivers/rtc . the rtc subsystem creates the device dynamically, you shouldn't count on having 254,0. I would eventually ack a patch that adds /dev/rtc at 10,135 as an alias for /dev/rtc0. however the best solution would be to upgrade hwclock. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Convert pfc8563 i2c driver from old style to new style
On Tue, 19 Feb 2008 16:10:20 +0100 Jean Delvare [EMAIL PROTECTED] wrote: Hi Jon, On Mon, 21 Jan 2008 15:09:01 -0500, Jon Smirl wrote: Convert pfc8563 i2c driver from old style to new style. Signed-off-by: Jon Smirl [EMAIL PROTECTED] --- drivers/rtc/rtc-pcf8563.c | 107 +++-- 1 files changed, 27 insertions(+), 80 deletions(-) Preliminary note: this driver belongs to the RTC subsystem, so it will be up to Alessandro Zummo (Cc'd) to push this patch upstream... when it is ready to go there. A conversion to new style for this driver has already been pushed upstream. Adapting platforms to instantiate the device should be fairly easy, especially when you use the dts. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
