On Tue, 30 Jan 2007 10:03:40 -0600
[email protected] (Olof Johansson) wrote:
> On Tue, Jan 30, 2007 at 12:37:12AM -0600, Kumar Gala wrote:
> >
> > On Jan 29, 2007, at 11:17 PM, Tom Rini wrote:
> >
> > >On Thu, Jan 25, 2007 at 01:37:54AM -0600, Olof Johansson wrote:
> > >
> > >>Make the PPC RTC functions use the generic RTC infrastructure if they
> > >>are not already defined (and an RTC is registered in the system).
> > >>
> > >>This should make it possible to remove the hideous direct access used
> > >>in some of the 83xx platforms.
> > >
> > >Now, I know I'm a bit late, and I've been quiet of late, but, um,
> > >why is
> > >there anything other than the RTC class stuff being used? I know
> > >drivers/char/genrtc.c isn't gone yet, but really, it should be in the
> > >process of being phased out. IMHO, it should depend on !POWERPC (or
> > >whatever the magic is to allow arch/ppc && !arch/powerpc).
> >
> > I think the problem was calling the RTC class code from the place's
> > we use rtc in ppc had locking issues or something like that.
>
> Yes, and it does a direct call into the driver instead of using the
> subsystem, exporting the symbol from the driver. Not a very pretty
> solution but it's possible that the genrtc stuff wasn't available when
> it was first implemented.
>
that's probably true.
afaict, this powerpc platform <--> RTC class code glue is totally unnecessary; RTC class sets things up fine on 83xx based boards that have rtc chips supported in RTC class (e.g., the ITX). I'm referring to the third bullet point here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116387226902131&w=2
For the MDS boards, which use the ds1374, I'd rather fix the problem properly and add a ds1374 driver to the RTC class. While Scott Wood (cc'd) has already done the port, I believe his patches are pending some patches by David Brownell.
Kim
On Tuesday 30 January 2007 11:25 am, Kim Phillips wrote:
>
> For the MDS boards, which use the ds1374, I'd rather fix the problem properly
> and add a ds1374 driver to the RTC class. While Scott Wood (cc'd) has already
> done the port, I believe his patches are pending some patches by David Brownell.
I can't imagine what such patches would be, unless maybe you're referring to
I2C framework updates that make it follow the driver model and support platform
specific data, like an RTC alarm's IRQ number? Those will take some time.
Just submit a normal I2C driver for that RTC, and any IRQ capability can be
added later. (Or as a board-specific patch, which seems to be the normal
solution for I2C, though they won't go upstream.)
- Dave