* [patch 0/3] fsl_soc / mpc8349emitx patches @ 2007-09-20 10:42 Peter Korsgaard 2007-09-20 10:42 ` [patch 1/3] fsl_soc: Fix trivial printk typo Peter Korsgaard ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw) To: linuxppc-dev, galak Various small fsl_soc / mpc8349emitx patches. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch 1/3] fsl_soc: Fix trivial printk typo. 2007-09-20 10:42 [patch 0/3] fsl_soc / mpc8349emitx patches Peter Korsgaard @ 2007-09-20 10:42 ` Peter Korsgaard 2007-09-20 10:42 ` [patch 2/3] fsl_soc: rtc-ds1307 support Peter Korsgaard 2007-09-20 10:42 ` [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC Peter Korsgaard 2 siblings, 0 replies; 18+ messages in thread From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw) To: linuxppc-dev, galak; +Cc: G. Liakhovetski Fix a trivial printk typo in fsl_soc. Cc: G. Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> --- arch/powerpc/sysdev/fsl_soc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/arch/powerpc/sysdev/fsl_soc.c =================================================================== --- linux.orig/arch/powerpc/sysdev/fsl_soc.c +++ linux/arch/powerpc/sysdev/fsl_soc.c @@ -346,7 +346,7 @@ addr = of_get_property(node, "reg", &len); if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) { - printk(KERN_WARNING "fsl_ioc.c: invalid i2c device entry\n"); + printk(KERN_WARNING "fsl_soc.c: invalid i2c device entry\n"); continue; } -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch 2/3] fsl_soc: rtc-ds1307 support 2007-09-20 10:42 [patch 0/3] fsl_soc / mpc8349emitx patches Peter Korsgaard 2007-09-20 10:42 ` [patch 1/3] fsl_soc: Fix trivial printk typo Peter Korsgaard @ 2007-09-20 10:42 ` Peter Korsgaard 2007-09-20 10:42 ` [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC Peter Korsgaard 2 siblings, 0 replies; 18+ messages in thread From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw) To: linuxppc-dev, galak; +Cc: G. Liakhovetski Add support for the I2C devices handled by the rtc-ds1307 driver to of_register_i2c_devices. Cc: G. Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> --- arch/powerpc/sysdev/fsl_soc.c | 6 ++++++ 1 file changed, 6 insertions(+) Index: linux/arch/powerpc/sysdev/fsl_soc.c =================================================================== --- linux.orig/arch/powerpc/sysdev/fsl_soc.c +++ linux/arch/powerpc/sysdev/fsl_soc.c @@ -319,6 +319,12 @@ {"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",}, {"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",}, {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",}, + {"dallas,ds1307", "rtc-ds1307", "ds1307",}, + {"dallas,ds1337", "rtc-ds1307", "ds1337",}, + {"dallas,ds1338", "rtc-ds1307", "ds1338",}, + {"dallas,ds1339", "rtc-ds1307", "ds1339",}, + {"dallas,ds1340", "rtc-ds1307", "ds1340",}, + {"stm,m41t00", "rtc-ds1307", "m41t00"}, }; static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info) -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-20 10:42 [patch 0/3] fsl_soc / mpc8349emitx patches Peter Korsgaard 2007-09-20 10:42 ` [patch 1/3] fsl_soc: Fix trivial printk typo Peter Korsgaard 2007-09-20 10:42 ` [patch 2/3] fsl_soc: rtc-ds1307 support Peter Korsgaard @ 2007-09-20 10:42 ` Peter Korsgaard 2007-09-20 13:35 ` Scott Wood 2 siblings, 1 reply; 18+ messages in thread From: Peter Korsgaard @ 2007-09-20 10:42 UTC (permalink / raw) To: linuxppc-dev, galak; +Cc: Timur Tabi Add ds1339 I2C RTC chip as child of 2nd I2C controller. Cc: Timur Tabi <timur@freescale.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> --- arch/powerpc/boot/dts/mpc8349emitx.dts | 7 +++++++ 1 file changed, 7 insertions(+) Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts =================================================================== --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts @@ -68,6 +68,13 @@ interrupts = <f 8>; interrupt-parent = < &ipic >; dfsrr; + + rtc@68 { + device_type = "rtc"; + compatible = "dallas,ds1339"; + reg = <68 4>; + }; + }; spi@7000 { -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-20 10:42 ` [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC Peter Korsgaard @ 2007-09-20 13:35 ` Scott Wood 2007-09-21 7:35 ` Peter Korsgaard 0 siblings, 1 reply; 18+ messages in thread From: Scott Wood @ 2007-09-20 13:35 UTC (permalink / raw) To: Peter Korsgaard; +Cc: linuxppc-dev, Timur Tabi On Thu, Sep 20, 2007 at 12:42:14PM +0200, Peter Korsgaard wrote: > Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts > =================================================================== > --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts > +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts > @@ -68,6 +68,13 @@ > interrupts = <f 8>; > interrupt-parent = < &ipic >; > dfsrr; > + > + rtc@68 { > + device_type = "rtc"; > + compatible = "dallas,ds1339"; > + reg = <68 4>; > + }; #size-cells is zero on i2c, so it should just be reg = <68>. You'll probably need to add #address-cells and #size-cells to the controller node, as well. -Scott ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-20 13:35 ` Scott Wood @ 2007-09-21 7:35 ` Peter Korsgaard 2007-09-24 5:07 ` David Gibson 0 siblings, 1 reply; 18+ messages in thread From: Peter Korsgaard @ 2007-09-21 7:35 UTC (permalink / raw) To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi >>>>> "Scott" == Scott Wood <scottwood@freescale.com> writes: Hi, Scott> #size-cells is zero on i2c, so it should just be reg = <68>. Scott> You'll probably need to add #address-cells and #size-cells to the Scott> controller node, as well. Ahh - Thanks. This should be better. --- [PATCH] mpc8349emitx.dts: Add ds1339 RTC Add ds1339 I2C RTC chip as child of 2nd I2C controller. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> --- arch/powerpc/boot/dts/mpc8349emitx.dts | 9 +++++++++ 1 file changed, 9 insertions(+) Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts =================================================================== --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts @@ -62,12 +62,21 @@ }; i2c@3100 { + #address-cells = <1>; + #size-cells = <0>; device_type = "i2c"; compatible = "fsl-i2c"; reg = <3100 100>; interrupts = <f 8>; interrupt-parent = < &ipic >; dfsrr; + + rtc@68 { + device_type = "rtc"; + compatible = "dallas,ds1339"; + reg = <68>; + }; + }; spi@7000 { -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-21 7:35 ` Peter Korsgaard @ 2007-09-24 5:07 ` David Gibson 2007-09-24 5:52 ` Peter Korsgaard ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: David Gibson @ 2007-09-24 5:07 UTC (permalink / raw) To: Peter Korsgaard; +Cc: linuxppc-dev, Timur Tabi On Fri, Sep 21, 2007 at 09:35:03AM +0200, Peter Korsgaard wrote: > >>>>> "Scott" == Scott Wood <scottwood@freescale.com> writes: > > Hi, > > Scott> #size-cells is zero on i2c, so it should just be reg = <68>. > > Scott> You'll probably need to add #address-cells and #size-cells to the > Scott> controller node, as well. Uh.. yes.. i2c interfaces should really always have #a and #s. > Ahh - Thanks. This should be better. > --- > > [PATCH] mpc8349emitx.dts: Add ds1339 RTC > > Add ds1339 I2C RTC chip as child of 2nd I2C controller. > > Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> > --- > arch/powerpc/boot/dts/mpc8349emitx.dts | 9 +++++++++ > 1 file changed, 9 insertions(+) > > Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts > =================================================================== > --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts > +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts > @@ -62,12 +62,21 @@ > }; > > i2c@3100 { > + #address-cells = <1>; > + #size-cells = <0>; > device_type = "i2c"; Hrm... we probably want an "i2c" device_type class, but I don't think we've actually defined one, which is a problem > compatible = "fsl-i2c"; > reg = <3100 100>; > interrupts = <f 8>; > interrupt-parent = < &ipic >; > dfsrr; > + > + rtc@68 { > + device_type = "rtc"; > + compatible = "dallas,ds1339"; > + reg = <68>; > + }; I think we want to think a bit more carefully about how to do bindings for RTC devices. No "rtc" device_type is defined, but again we might want to. I did find one real OF binding for a different Dallas RTC (and NVRAM), see: http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-it.txt It's a little different from the example above. The fact that NVRAM+RTC chips are so common is a bit of an issue from the point of view of defining a device class binding - a device can't have type "rtc" and "nvram". > + > }; > > spi@7000 { > -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 5:07 ` David Gibson @ 2007-09-24 5:52 ` Peter Korsgaard 2007-09-25 2:13 ` David Gibson 2007-09-24 6:13 ` Kumar Gala ` (2 subsequent siblings) 3 siblings, 1 reply; 18+ messages in thread From: Peter Korsgaard @ 2007-09-24 5:52 UTC (permalink / raw) To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi >>>>> "David" == David Gibson <david@gibson.dropbear.id.au> writes: Hi >> compatible = "fsl-i2c"; >> reg = <3100 100>; >> interrupts = <f 8>; >> interrupt-parent = < &ipic >; >> dfsrr; >> + >> + rtc@68 { >> + 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. But I'm open for suggestions. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 5:52 ` Peter Korsgaard @ 2007-09-25 2:13 ` David Gibson 2007-09-25 5:33 ` Peter Korsgaard 0 siblings, 1 reply; 18+ messages in thread From: David Gibson @ 2007-09-25 2:13 UTC (permalink / raw) To: Peter Korsgaard; +Cc: linuxppc-dev, Timur Tabi On Mon, Sep 24, 2007 at 07:52:22AM +0200, Peter Korsgaard wrote: > >>>>> "David" == David Gibson <david@gibson.dropbear.id.au> writes: > > Hi > > >> compatible = "fsl-i2c"; > >> reg = <3100 100>; > >> interrupts = <f 8>; > >> interrupt-parent = < &ipic >; > >> dfsrr; > >> + > >> + rtc@68 { > >> + 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-25 2:13 ` David Gibson @ 2007-09-25 5:33 ` Peter Korsgaard 2007-09-25 5:47 ` David Gibson 0 siblings, 1 reply; 18+ messages in thread From: Peter Korsgaard @ 2007-09-25 5:33 UTC (permalink / raw) To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi >>>>> "David" == David Gibson <david@gibson.dropbear.id.au> writes: Hi, >> The Linux driver for the chip (rtc-1307.c) doesn't expose the NVRAM >> bytes either. David> Incidentally how are you planning on instantiating the driver? AFAIK David> all the rtc-* drivers are platform drivers rather than of_platform David> drivers. I had been thinking of an rtc helper function that would go David> through the tree instantiating platform devices for any RTCs based on David> a compatible -> platform device name table. Please see patch #2 in the series: http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042896.html That helper function more or less already exists in fsl_soc.c. -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-25 5:33 ` Peter Korsgaard @ 2007-09-25 5:47 ` David Gibson 0 siblings, 0 replies; 18+ messages in thread From: David Gibson @ 2007-09-25 5:47 UTC (permalink / raw) To: Peter Korsgaard; +Cc: linuxppc-dev, Timur Tabi On Tue, Sep 25, 2007 at 07:33:15AM +0200, Peter Korsgaard wrote: > >>>>> "David" == David Gibson <david@gibson.dropbear.id.au> writes: > > Hi, > > >> The Linux driver for the chip (rtc-1307.c) doesn't expose the NVRAM > >> bytes either. > > David> Incidentally how are you planning on instantiating the driver? AFAIK > David> all the rtc-* drivers are platform drivers rather than of_platform > David> drivers. I had been thinking of an rtc helper function that would go > David> through the tree instantiating platform devices for any RTCs based on > David> a compatible -> platform device name table. > > Please see patch #2 in the series: > > http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042896.html > > That helper function more or less already exists in fsl_soc.c. Ah, I see. Well... it exists for i2c devices (possibly including RTCs). Whereas I was thinking of a version for RTCs (possibly including i2c devices). Actually that won't quite work - looks like the i2c RTC class drivers are probed differently from the RTC drivers I was looking at which are pure platform devices. -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 5:07 ` David Gibson 2007-09-24 5:52 ` Peter Korsgaard @ 2007-09-24 6:13 ` Kumar Gala 2007-09-24 14:52 ` Scott Wood 2007-09-24 21:11 ` Segher Boessenkool 3 siblings, 0 replies; 18+ messages in thread From: Kumar Gala @ 2007-09-24 6:13 UTC (permalink / raw) To: David Gibson; +Cc: Timur Tabi, linuxppc-dev On Sep 24, 2007, at 12:07 AM, David Gibson wrote: > On Fri, Sep 21, 2007 at 09:35:03AM +0200, Peter Korsgaard wrote: >>>>>>> "Scott" == Scott Wood <scottwood@freescale.com> writes: >> >> Hi, >> >> Scott> #size-cells is zero on i2c, so it should just be reg = <68>. >> >> Scott> You'll probably need to add #address-cells and #size-cells >> to the >> Scott> controller node, as well. > > Uh.. yes.. i2c interfaces should really always have #a and #s. > >> Ahh - Thanks. This should be better. >> --- >> >> [PATCH] mpc8349emitx.dts: Add ds1339 RTC >> >> Add ds1339 I2C RTC chip as child of 2nd I2C controller. >> >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> >> --- >> arch/powerpc/boot/dts/mpc8349emitx.dts | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts >> =================================================================== >> --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts >> +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts >> @@ -62,12 +62,21 @@ >> }; >> >> i2c@3100 { >> + #address-cells = <1>; >> + #size-cells = <0>; >> device_type = "i2c"; > > Hrm... we probably want an "i2c" device_type class, but I don't think > we've actually defined one, which is a prob suggestions on how to handle this? We've described that fsl-i2c nodes in booting-without-of.txt should have it. (which may have been wrong at the time). - k > >> compatible = "fsl-i2c"; >> reg = <3100 100>; >> interrupts = <f 8>; >> interrupt-parent = < &ipic >; >> dfsrr; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 5:07 ` David Gibson 2007-09-24 5:52 ` Peter Korsgaard 2007-09-24 6:13 ` Kumar Gala @ 2007-09-24 14:52 ` Scott Wood 2007-09-25 2:04 ` David Gibson 2007-09-24 21:11 ` Segher Boessenkool 3 siblings, 1 reply; 18+ messages in thread From: Scott Wood @ 2007-09-24 14:52 UTC (permalink / raw) To: Peter Korsgaard, Scott Wood, linuxppc-dev, Timur Tabi David Gibson wrote: >> i2c@3100 { >> + #address-cells = <1>; >> + #size-cells = <0>; >> device_type = "i2c"; > > Hrm... we probably want an "i2c" device_type class, but I don't think > we've actually defined one, which is a problem Right... but we need to get the kernel to stop expecting the device type to be there before we yell at people for including it. :-) > The fact that NVRAM+RTC chips are so common is a bit of an issue from > the point of view of defining a device class binding - a device can't > have type "rtc" and "nvram". This is one of the reasons that I'd prefer to use compatible for such things. -Scott ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 14:52 ` Scott Wood @ 2007-09-25 2:04 ` David Gibson 0 siblings, 0 replies; 18+ messages in thread From: David Gibson @ 2007-09-25 2:04 UTC (permalink / raw) To: Scott Wood; +Cc: Timur Tabi, linuxppc-dev On Mon, Sep 24, 2007 at 09:52:31AM -0500, Scott Wood wrote: > David Gibson wrote: > >> i2c@3100 { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> device_type = "i2c"; > > > > Hrm... we probably want an "i2c" device_type class, but I don't think > > we've actually defined one, which is a problem > > Right... but we need to get the kernel to stop expecting the device type > to be there before we yell at people for including it. :-) Obviously. We should make sure all the corresponding compatibles are specific enough, change the drivers, then think about getting rid of it. > > The fact that NVRAM+RTC chips are so common is a bit of an issue from > > the point of view of defining a device class binding - a device can't > > have type "rtc" and "nvram". > > This is one of the reasons that I'd prefer to use compatible for such > things. Yeah, fair enough. -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 5:07 ` David Gibson ` (2 preceding siblings ...) 2007-09-24 14:52 ` Scott Wood @ 2007-09-24 21:11 ` Segher Boessenkool 2007-09-25 2:11 ` David Gibson 3 siblings, 1 reply; 18+ messages in thread From: Segher Boessenkool @ 2007-09-24 21:11 UTC (permalink / raw) To: David Gibson; +Cc: Timur Tabi, linuxppc-dev >> Scott> #size-cells is zero on i2c, so it should just be reg = <68>. >> >> Scott> You'll probably need to add #address-cells and #size-cells to >> the >> Scott> controller node, as well. > > Uh.. yes.. i2c interfaces should really always have #a and #s. More generally, every node that defines a bus needs it (unless the defaults of 2 resp. 1 are correct for this bus, but even then you might want it because it makes things more explicit). >> i2c@3100 { >> + #address-cells = <1>; >> + #size-cells = <0>; >> device_type = "i2c"; > > Hrm... we probably want an "i2c" device_type class, but I don't think > we've actually defined one, which is a problem By defining new device_type's, or new semantics for device_type, you open the door to (accidentally) becoming incompatible with "real" OF. And you don't need to: "real" OF has a mechanism for specifying the "generic device class" already, if you use the "generic names" recommended practice (and you do, for both this node and the rtc node): it's the generic name itself! >> + rtc@68 { >> + device_type = "rtc"; >> + compatible = "dallas,ds1339"; >> + reg = <68>; >> + }; > > I think we want to think a bit more carefully about how to do bindings > for RTC devices. No "rtc" device_type is defined, but again we might > want to. Actually, "device_type" = "rtc" _is_ defined (in the "device support extensions" recommended practice), and there is no useful way a flat device tree can implement it (it merely defines get-time and set-time methods). > The fact that NVRAM+RTC chips are so common is a bit of an issue from > the point of view of defining a device class binding - a device can't > have type "rtc" and "nvram". You should match OS drivers on "compatible" only anyway. Those cases where OS drivers don't nicely 1-1 match device nodes are a bit of a headache; for RTC/NVRAM devices, these problems are nicely side-stepped by handling this from platform code. Segher ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-24 21:11 ` Segher Boessenkool @ 2007-09-25 2:11 ` David Gibson 2007-09-25 20:33 ` Segher Boessenkool 0 siblings, 1 reply; 18+ messages in thread From: David Gibson @ 2007-09-25 2:11 UTC (permalink / raw) To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi On Mon, Sep 24, 2007 at 11:11:28PM +0200, Segher Boessenkool wrote: > >> Scott> #size-cells is zero on i2c, so it should just be reg = <68>. > >> > >> Scott> You'll probably need to add #address-cells and #size-cells to > >> the > >> Scott> controller node, as well. > > > > Uh.. yes.. i2c interfaces should really always have #a and #s. > > More generally, every node that defines a bus needs it (unless the > defaults of 2 resp. 1 are correct for this bus, but even then you > might want it because it makes things more explicit). Yes. Actually I think we should make explicit #a and #s at least strongly recommended in the flat tree documentation. > >> i2c@3100 { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> device_type = "i2c"; > > > > Hrm... we probably want an "i2c" device_type class, but I don't think > > we've actually defined one, which is a problem > > By defining new device_type's, or new semantics for device_type, > you open the door to (accidentally) becoming incompatible with > "real" OF. Hrm... perhaps. But is it a realistic danger - I'll have to think more about that. > And you don't need to: "real" OF has a mechanism for specifying > the "generic device class" already, if you use the "generic names" > recommended practice (and you do, for both this node and the rtc > node): it's the generic name itself! Hmm, I guess. > >> + rtc@68 { > >> + device_type = "rtc"; > >> + compatible = "dallas,ds1339"; > >> + reg = <68>; > >> + }; > > > > I think we want to think a bit more carefully about how to do bindings > > for RTC devices. No "rtc" device_type is defined, but again we might > > want to. > > Actually, "device_type" = "rtc" _is_ defined (in the "device support > extensions" recommended practice), and there is no useful way a flat > device tree can implement it (it merely defines get-time and set-time > methods). Ah.. right. That changes things a bit, in that we might want to include device_type purely for similarity with real OF tree. Real OF has a device_type == "nvram" too, doesn't it? AFAICT the real OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM chips) the RTC is labelled as "nvram" rather than "rtc". > > The fact that NVRAM+RTC chips are so common is a bit of an issue from > > the point of view of defining a device class binding - a device can't > > have type "rtc" and "nvram". > > You should match OS drivers on "compatible" only anyway. Absolutely. I was only thinking of defining "device classes" where for some reason it is useful to examine them without needing to pick a particular driver. > Those cases where OS drivers don't nicely 1-1 match device nodes are a > bit of a headache; for RTC/NVRAM devices, these problems are nicely > side-stepped by handling this from platform code. Not necessarily. The new RTC class drivers are just drivers like anything other and are not especially instantiated from the platform code. And drat. I was only really mentioning stuff about device_type in passing, but it's the only thing anyone's responded to. I was also mostly suggesting changing the format of compatible, for greater similarity with the existing ds1385 binding. -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-25 2:11 ` David Gibson @ 2007-09-25 20:33 ` Segher Boessenkool 2007-09-28 2:45 ` David Gibson 0 siblings, 1 reply; 18+ messages in thread From: Segher Boessenkool @ 2007-09-25 20:33 UTC (permalink / raw) To: David Gibson; +Cc: linuxppc-dev, Timur Tabi >>> Hrm... we probably want an "i2c" device_type class, but I don't think >>> we've actually defined one, which is a problem >> >> By defining new device_type's, or new semantics for device_type, >> you open the door to (accidentally) becoming incompatible with >> "real" OF. > > Hrm... perhaps. But is it a realistic danger - I'll have to think > more about that. It is trivial to avoid these dangers completely by not overloading the meaning of "device_type". >>> I think we want to think a bit more carefully about how to do >>> bindings >>> for RTC devices. No "rtc" device_type is defined, but again we might >>> want to. >> >> Actually, "device_type" = "rtc" _is_ defined (in the "device support >> extensions" recommended practice), and there is no useful way a flat >> device tree can implement it (it merely defines get-time and set-time >> methods). > > Ah.. right. That changes things a bit, in that we might want to > include device_type purely for similarity with real OF tree. You should include the device_type only if you implement its binding, and a flat device tree does not, and cannot. (In almost all cases, a flat device tree cannot implement device_type's semantics -- this means that pretty much the only case where a flat tree should use device_type is to have it as a workaround for bad kernel requirements). > Real OF has a device_type == "nvram" too, doesn't it? Yes, same "device support extensions" document. > AFAICT the real > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM > chips) the RTC is labelled as "nvram" rather than "rtc". Sounds buggy. >>> The fact that NVRAM+RTC chips are so common is a bit of an issue from >>> the point of view of defining a device class binding - a device can't >>> have type "rtc" and "nvram". >> >> You should match OS drivers on "compatible" only anyway. > > Absolutely. I was only thinking of defining "device classes" where > for some reason it is useful to examine them without needing to pick a > particular driver. Yeah I understand. In what situations would this be useful? Answering that question will make the requirements for this more clear; or maybe it will show we do not need this at all. >> Those cases where OS drivers don't nicely 1-1 match device nodes are a >> bit of a headache; for RTC/NVRAM devices, these problems are nicely >> side-stepped by handling this from platform code. > > Not necessarily. The new RTC class drivers are just drivers like > anything other and are not especially instantiated from the platform > code. I meant "can be nicely side-stepped", or "usually are ..." :-) Obviously, when you cannot avoid the problem, you have a problem. > And drat. I was only really mentioning stuff about device_type in > passing, but it's the only thing anyone's responded to. I was also > mostly suggesting changing the format of compatible, for greater > similarity with the existing ds1385 binding. Okay, quoting from your earlier message: > I did find one real OF binding for a different Dallas RTC (and NVRAM), > see: > > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346- > it.txt > > It's a little different from the example above. That is a binding for the nvram part only, not for the RTC. Segher ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC 2007-09-25 20:33 ` Segher Boessenkool @ 2007-09-28 2:45 ` David Gibson 0 siblings, 0 replies; 18+ messages in thread From: David Gibson @ 2007-09-28 2:45 UTC (permalink / raw) To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi On Tue, Sep 25, 2007 at 10:33:58PM +0200, Segher Boessenkool wrote: > >>> Hrm... we probably want an "i2c" device_type class, but I don't think > >>> we've actually defined one, which is a problem > >> > >> By defining new device_type's, or new semantics for device_type, > >> you open the door to (accidentally) becoming incompatible with > >> "real" OF. > > > > Hrm... perhaps. But is it a realistic danger - I'll have to think > > more about that. > > It is trivial to avoid these dangers completely by not overloading > the meaning of "device_type". Hrm. Perhaps. > >>> I think we want to think a bit more carefully about how to do > >>> bindings > >>> for RTC devices. No "rtc" device_type is defined, but again we might > >>> want to. > >> > >> Actually, "device_type" = "rtc" _is_ defined (in the "device support > >> extensions" recommended practice), and there is no useful way a flat > >> device tree can implement it (it merely defines get-time and set-time > >> methods). > > > > Ah.. right. That changes things a bit, in that we might want to > > include device_type purely for similarity with real OF tree. > > You should include the device_type only if you implement its binding, > and a flat device tree does not, and cannot. (In almost all cases, > a flat device tree cannot implement device_type's semantics -- this > means that pretty much the only case where a flat tree should use > device_type is to have it as a workaround for bad kernel requirements). I really don't think there's an ambiguity here. A flat-tree can clearly never implement runtime binding features. This is also true for a flat tree derived from a real OF, and so full of device_type all over the place. > > Real OF has a device_type == "nvram" too, doesn't it? > > Yes, same "device support extensions" document. Erm.. I've lost track amongst our various threads. Which same document? > > AFAICT the real > > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM > > chips) the RTC is labelled as "nvram" rather than "rtc". > > Sounds buggy. Why? [snip] > > I did find one real OF binding for a different Dallas RTC (and NVRAM), > > see: > > > > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346- > > it.txt > > > > It's a little different from the example above. > > That is a binding for the nvram part only, not for the RTC. Hrm. So how do you suggest we do bindings for combined devices? -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2007-09-28 2:45 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-20 10:42 [patch 0/3] fsl_soc / mpc8349emitx patches Peter Korsgaard 2007-09-20 10:42 ` [patch 1/3] fsl_soc: Fix trivial printk typo Peter Korsgaard 2007-09-20 10:42 ` [patch 2/3] fsl_soc: rtc-ds1307 support Peter Korsgaard 2007-09-20 10:42 ` [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC Peter Korsgaard 2007-09-20 13:35 ` Scott Wood 2007-09-21 7:35 ` Peter Korsgaard 2007-09-24 5:07 ` David Gibson 2007-09-24 5:52 ` Peter Korsgaard 2007-09-25 2:13 ` David Gibson 2007-09-25 5:33 ` Peter Korsgaard 2007-09-25 5:47 ` David Gibson 2007-09-24 6:13 ` Kumar Gala 2007-09-24 14:52 ` Scott Wood 2007-09-25 2:04 ` David Gibson 2007-09-24 21:11 ` Segher Boessenkool 2007-09-25 2:11 ` David Gibson 2007-09-25 20:33 ` Segher Boessenkool 2007-09-28 2:45 ` David Gibson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.