On Fri, 27 Feb 2009, Richard Zidlicky wrote:
> On Wed, Feb 25, 2009 at 11:18:36AM +0100, Alessandro Zummo wrote:
> > On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
> > Geert Uytterhoeven <[email protected]> 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.
>
> seems like so far ppc is the only architecture attempting to implement it
> correctly, all others either have it unimplemented or use the broken
> by design set_rtc_mmss method.
> Also note that in most cases hwclock has much better possibilities
> to do a good job.
>
> Regarding genrtc vs rtc-ppc/rtc-generic it is worth noting that genrtc
> provides RTC_UIE emulation which is of some use for exotic programs like
> "chrony".
> Afaics this is also the only situation without a good userspace workaround
> and chrony never worked well for me so I have nothing against junking the
> code.
What about CONFIG_RTC_INTF_DEV_UIE_EMUL for RTC class devices?
> Regarding a possible reorganisation from the generic to all separate drivers
> I agree that the habit of putting rtc-chip specific code in asm-generic is
> confusing at best.
> In many cases such code might be better placed in drivers/rtc or
> include/linux/rtc/chipname.
>
> Imho this does not preclude the possibility to use a generic framework. While
> there certainly are valid reasons to have separate drivers in some cases
> I do not see much value in rewriting everything as separate drivers where
> the generic framework works well.
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.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
On Mon, 2 Mar 2009 10:54:14 +0100 (CET)
Geert Uytterhoeven <[email protected]> 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
On Mon, 2 Mar 2009, Alessandro Zummo wrote:
> On Mon, 2 Mar 2009 10:54:14 +0100 (CET)
> Geert Uytterhoeven <[email protected]> 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.
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.
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.
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.
> 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.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010
On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
Geert Uytterhoeven <[email protected]> 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
On Mon, 2 Mar 2009, Alessandro Zummo wrote:
> On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
> Geert Uytterhoeven <[email protected]> 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.
I know.
> 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.
rtc-generic is already in the kernel, it's just called rtc-parisc ;-)
> 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.
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010
On Tue, 3 Mar 2009 11:41:23 +0100 (CET)
Geert Uytterhoeven <[email protected]> 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
On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote:
> 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.
>
Did you miss the rtc-firmware thread?
http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98966048f66/1d730cb4aa2f85f0?lnk=gst&q=rtc-firmware#1d730cb4aa2f85f0
http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gst&q=rtc-firmware#cb9c1530d9c3a433
On Wed, 4 Mar 2009, Paul Mundt wrote:
> On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote:
> > 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.
> >
> Did you miss the rtc-firmware thread?
>
> http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98966048f66/1d730cb4aa2f85f0?lnk=gst&q=rtc-firmware#1d730cb4aa2f85f0
> http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gst&q=rtc-firmware#cb9c1530d9c3a433
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.
Seems like everybody but the RTC maintainer has an interest in having an RTC
class driver on top of [gs]et_rtc_time()... ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010
On Wed, 4 Mar 2009 09:26:29 +0100 (CET)
Geert Uytterhoeven <[email protected]> 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
On Wed, 4 Mar 2009, Alessandro Zummo wrote:
> On Wed, 4 Mar 2009 09:26:29 +0100 (CET)
> Geert Uytterhoeven <[email protected]> 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.
OK, I will do so. Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010