On Mon, Sep 24, 2007 at 07:52:22AM +0200, Peter Korsgaard wrote:
> >>>>> "David" == David Gibson <[EMAIL PROTECTED]> writes:
>
> Hi
>
> >> compatible = "fsl-i2c";
> >> reg = <3100 100>;
> >> interrupts = <f 8>;
> >> interrupt-parent = < &ipic >;
> >> dfsrr;
> >> +
> >> + [EMAIL PROTECTED] {
> >> + device_type = "rtc";
> >> + compatible = "dallas,ds1339";
> >> + reg = <68>;
> >> + };
>
> David> I think we want to think a bit more carefully about how to do bindings
> David> for RTC devices. No "rtc" device_type is defined, but again we might
> David> want to.
>
> Could be. I've simply done it like kuroboxHD.dts already does and
> fsl_soc.c expects.
>
> David> I did find one real OF binding for a different Dallas RTC (and NVRAM),
> David> see:
>
> David>
> http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-it.txt
>
> David> It's a little different from the example above.
>
> David> The fact that NVRAM+RTC chips are so common is a bit of an issue from
> David> the point of view of defining a device class binding - a device can't
> David> have type "rtc" and "nvram".
>
> True. I think we should primarily focus on the RTC part rather than
> NVRAM as that's the "main" functionality and leave a NVRAM class for
> I2C EEPROMs.
>
> The Linux driver for the chip (rtc-1307.c) doesn't expose the NVRAM
> bytes either.
Incidentally how are you planning on instantiating the driver? AFAIK
all the rtc-* drivers are platform drivers rather than of_platform
drivers. I had been thinking of an rtc helper function that would go
through the tree instantiating platform devices for any RTCs based on
a compatible -> platform device name table.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
