* RE: Review Request: New proposal for device tree clock binding. [not found] <AANLkTimm7G--LQHYBqPB1YCXQb7fSXPDaYsLq0p30DG1@mail.gmail.com> @ 2010-08-09 4:50 ` Li Yang-R58472 2010-08-09 5:28 ` Grant Likely 0 siblings, 1 reply; 6+ messages in thread From: Li Yang-R58472 @ 2010-08-09 4:50 UTC (permalink / raw) To: Grant Likely, devicetree-discuss, Jeremy Kerr, Benjamin Herrenschmidt Cc: linuxppc-dev It looks like the previous sending didn't hit the mailing list. Resend. Hi Grant, I have some comment on this proposal. >Subject: Review Request: New proposal for device tree clock binding. > >Hi Ben (well, hello to everyone, but I'm particularly interested in=20 >Ben's feedback), > >Jeremy and I have been kicking around the clock binding, and we've come = >up with a new proposal that doesn't feel quite as forced to me. >Please take a look and let me know what you think. The link to the=20 >binding is below[1], but I've also copied the full text so that you can = >reply and comment. The rational for the new binding can be found in=20 >talk page[2]. > >[1] http://www.devicetree.org/ClockBindings >[2] http://www.devicetree.org/Talk:ClockBindings > >--- > >This page descibes the proposed OF clock bindings. These are a work-in- = >progress, and are based on some=20 >[http://patchwork.ozlabs.org/patch/31551/ >experimental work by benh]. > >=3D=3DClock providers=3D=3D > >Sources of clock signal can be represented by any node in the device = tree. >A mandatory "<tt>clock-outputs</tt>" property describes the clock=20 >outputs from this device. > >{|border=3D1 >!property >!format >!notes >|- >|<tt>clock-outputs</tt> >|list of strings >|specifies output clock signal names. >|} > >For example: > > oscillator { > clock-outputs =3D "ckil", "ckih"; > }; > >- this node defines a device with two clock outputs, the first named=20 >"ckil" and the second named "ckih". Consumer nodes always reference=20 >clocks by name. The names should reflect the clock output signal names = >for the device. > >=3D=3DClock consumers=3D=3D > >A device connected to a clock signal needs a *-clock property for each=20 >clock that it is connected to. > >{|border=3D1 >!property >!format >!notes >|- >|<tt>*-clock</tt> >|1 cell phandle to the clock provider, followed by a string containing >the clock output name. >|The name of this property should be the name of the clock input >signal with a "-clock" suffix. >|} > ><tt>*-clock</tt> is named for the signal name for the ''clock input'' >of the device. it should describe the function of the signal for that=20 >device, rather than the name of the system-wide clock line. For=20 >example, a UART with two clocks - one for baud-rate clocking, and the=20 >other for register clocking - may have clock input properties named=20 >"baud-clock" and "register-clock". The property value is a tuple=20 >containing the phandle to the clock provider and the name of the clock = output signal. > >For example: > > uart { > baud-clock =3D <&osc>, "ckil"; > register-clock =3D <&ref>, "bus"; > }; > > >This represents a device with two clock inputs, named "baud" and=20 >"register". The baud clock is connected to the "ckil" output of the = "osc" >device, and the register clock is connected to the "bus" output of the=20 >"ref" device. Instead of having two items to identify a clock, I would suggest to have = a node for each clock. So that clock can be referenced by one handle. = Also we can have clock specific information defined in the clock node. = Here is the example I am planning to use on 85xx PMC. power@e0070{ compatible =3D "fsl,mpc8548-pmc", = "fsl,p2020-pmc"; reg =3D <0xe0070 0x20>; etsec1_clk: soc-clk@24{ fsl,pmcdr-mask =3D <0x00000080>; }; etsec2_clk: soc-clk@25{ fsl,pmcdr-mask =3D <0x00000040>; }; etsec3_clk: soc-clk@26{ fsl,pmcdr-mask =3D <0x00000020>; }; }; enet0: ethernet@24000 { ...... master-clock =3D <&etsec1_clk>; ...... What do you think? - Leo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Review Request: New proposal for device tree clock binding. 2010-08-09 4:50 ` Review Request: New proposal for device tree clock binding Li Yang-R58472 @ 2010-08-09 5:28 ` Grant Likely 2010-08-09 7:05 ` Li Yang-R58472 0 siblings, 1 reply; 6+ messages in thread From: Grant Likely @ 2010-08-09 5:28 UTC (permalink / raw) To: Li Yang-R58472; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr On Sun, Aug 8, 2010 at 10:50 PM, Li Yang-R58472 <r58472@freescale.com> wrot= e: > It looks like the previous sending didn't hit the mailing list. =A0Resend= . > > Hi Grant, > > I have some comment on this proposal. The email addr you're using isn't subscribed, so mailman held the message for moderation. I've approved it now and added you address to the accept list. Anyway, I received it and here is my reply: http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-August/002706.htm= l Cheers, g. > >>Subject: Review Request: New proposal for device tree clock binding. >> >>Hi Ben (well, hello to everyone, but I'm particularly interested in >>Ben's feedback), >> >>Jeremy and I have been kicking around the clock binding, and we've come >>up with a new proposal that doesn't feel quite as forced to me. >>Please take a look and let me know what you think. =A0The link to the >>binding is below[1], but I've also copied the full text so that you can >>reply and comment. =A0The rational for the new binding can be found in >>talk page[2]. >> >>[1] http://www.devicetree.org/ClockBindings >>[2] http://www.devicetree.org/Talk:ClockBindings >> >>--- >> >>This page descibes the proposed OF clock bindings. These are a work-in- >>progress, and are based on some >>[http://patchwork.ozlabs.org/patch/31551/ >>experimental work by benh]. >> >>=3D=3DClock providers=3D=3D >> >>Sources of clock signal can be represented by any node in the device tree= . >>A mandatory "<tt>clock-outputs</tt>" property describes the clock >>outputs from this device. >> >>{|border=3D1 >>!property >>!format >>!notes >>|- >>|<tt>clock-outputs</tt> >>|list of strings >>|specifies output clock signal names. >>|} >> >>For example: >> >> =A0 =A0oscillator { >> =A0 =A0 =A0 =A0clock-outputs =3D "ckil", "ckih"; >> =A0 =A0}; >> >>- this node defines a device with two clock outputs, the first named >>"ckil" and the second named "ckih". =A0Consumer nodes always reference >>clocks by name. =A0The names should reflect the clock output signal names >>for the device. >> >>=3D=3DClock consumers=3D=3D >> >>A device connected to a clock signal needs a *-clock property for each >>clock that it is connected to. >> >>{|border=3D1 >>!property >>!format >>!notes >>|- >>|<tt>*-clock</tt> >>|1 cell phandle to the clock provider, followed by a string containing >>the clock output name. >>|The name of this property should be the name of the clock input >>signal with a "-clock" suffix. >>|} >> >><tt>*-clock</tt> is named for the signal name for the ''clock input'' >>of the device. it should describe the function of the signal for that >>device, rather than the name of the system-wide clock line. For >>example, a UART with two clocks - one for baud-rate clocking, and the >>other for register clocking - may have clock input properties named >>"baud-clock" and "register-clock". =A0The property value is a tuple >>containing the phandle to the clock provider and the name of the clock ou= tput signal. >> >>For example: >> >> =A0 =A0uart { >> =A0 =A0 =A0 =A0baud-clock =3D <&osc>, "ckil"; >> =A0 =A0 =A0 =A0register-clock =3D <&ref>, "bus"; >> =A0 =A0}; >> >> >>This represents a device with two clock inputs, named "baud" and >>"register". The baud clock is connected to the "ckil" output of the "osc" >>device, and the register clock is connected to the "bus" output of the >>"ref" device. > > > Instead of having two items to identify a clock, I would suggest to have = a node for each clock. =A0So that clock can be referenced by one handle. = =A0Also we can have clock specific information defined in the clock node. = =A0Here is the example I am planning to use on 85xx PMC. > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power@e0070{ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc854= 8-pmc", "fsl,p2020-pmc"; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xe0070 0x20>; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec1_clk: soc-clk@24{ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcdr-= mask =3D <0x00000080>; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec2_clk: soc-clk@25{ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcdr-= mask =3D <0x00000040>; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec3_clk: soc-clk@26{ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcdr-= mask =3D <0x00000020>; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enet0: ethernet@24000 { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...... > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master-clock =3D <&etsec1_= clk>; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...... > > > What do you think? > > - Leo > > > --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Review Request: New proposal for device tree clock binding. 2010-08-09 5:28 ` Grant Likely @ 2010-08-09 7:05 ` Li Yang-R58472 2010-08-09 7:12 ` Grant Likely 0 siblings, 1 reply; 6+ messages in thread From: Li Yang-R58472 @ 2010-08-09 7:05 UTC (permalink / raw) To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr >>><tt>*-clock</tt> is named for the signal name for the ''clock input'' >>>of the device. it should describe the function of the signal for that >>>device, rather than the name of the system-wide clock line. For >>>example, a UART with two clocks - one for baud-rate clocking, and the >>>other for register clocking - may have clock input properties named >>>"baud-clock" and "register-clock". =A0The property value is a tuple >>>containing the phandle to the clock provider and the name of the = clock >output signal. >>> >>>For example: >>> >>> =A0 =A0uart { >>> =A0 =A0 =A0 =A0baud-clock =3D <&osc>, "ckil"; >>> =A0 =A0 =A0 =A0register-clock =3D <&ref>, "bus"; >>> =A0 =A0}; >>> >>> >>>This represents a device with two clock inputs, named "baud" and >>>"register". The baud clock is connected to the "ckil" output of the >"osc" >>>device, and the register clock is connected to the "bus" output of = the >>>"ref" device. >> >> >> Instead of having two items to identify a clock, I would suggest to = have >a node for each clock. =A0So that clock can be referenced by one >handle. =A0Also we can have clock specific information defined in the = clock >node. =A0Here is the example I am planning to use on 85xx PMC. >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power@e0070{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D = "fsl,mpc8548-pmc", >> "fsl,p2020-pmc"; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xe0070 = 0x20>; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec1_clk: = soc-clk@24{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0fsl,pmcdr-mask =3D <0x00000080>; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec2_clk: = soc-clk@25{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0fsl,pmcdr-mask =3D <0x00000040>; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec3_clk: = soc-clk@26{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0fsl,pmcdr-mask =3D <0x00000020>; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enet0: ethernet@24000 { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...... >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master-clock =3D = <&etsec1_clk>; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...... >> >> >> What do you think? Quoting your reply: > I've avoided requiring clock nodes to have a separate sub node for > each output because it is more verbose and it prevents clock providers > from having child nodes for other purposes. Are you concerned that I don't see why there should be child nodes for other purposes under = clock node. > having the <phandle>+output name pair will be difficult to manage? That's part of my concern. But my main concern is the inability of = describing the properties of each clock in the device tree. The clock = stuff is much SoC related, which means it could be variable among chips = even in a same family. Having clock properties defined in device tree = will make it easier to have an abstracted driver to handle clock = operations. That's why device trees are used in the first place, right? - Leo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Review Request: New proposal for device tree clock binding. 2010-08-09 7:05 ` Li Yang-R58472 @ 2010-08-09 7:12 ` Grant Likely 2010-08-10 4:56 ` Li Yang-R58472 0 siblings, 1 reply; 6+ messages in thread From: Grant Likely @ 2010-08-09 7:12 UTC (permalink / raw) To: Li Yang-R58472; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr On Mon, Aug 9, 2010 at 1:05 AM, Li Yang-R58472 <r58472@freescale.com> wrote= : >>>><tt>*-clock</tt> is named for the signal name for the ''clock input'' >>>>of the device. it should describe the function of the signal for that >>>>device, rather than the name of the system-wide clock line. For >>>>example, a UART with two clocks - one for baud-rate clocking, and the >>>>other for register clocking - may have clock input properties named >>>>"baud-clock" and "register-clock". =A0The property value is a tuple >>>>containing the phandle to the clock provider and the name of the clock >>output signal. >>>> >>>>For example: >>>> >>>> =A0 =A0uart { >>>> =A0 =A0 =A0 =A0baud-clock =3D <&osc>, "ckil"; >>>> =A0 =A0 =A0 =A0register-clock =3D <&ref>, "bus"; >>>> =A0 =A0}; >>>> >>>> >>>>This represents a device with two clock inputs, named "baud" and >>>>"register". The baud clock is connected to the "ckil" output of the >>"osc" >>>>device, and the register clock is connected to the "bus" output of the >>>>"ref" device. >>> >>> >>> Instead of having two items to identify a clock, I would suggest to hav= e >>a node for each clock. =A0So that clock can be referenced by one >>handle. =A0Also we can have clock specific information defined in the clo= ck >>node. =A0Here is the example I am planning to use on 85xx PMC. >>> >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power@e0070{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc8= 548-pmc", >>> "fsl,p2020-pmc"; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xe0070 0x20>; >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec1_clk: soc-clk@24{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcd= r-mask =3D <0x00000080>; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec2_clk: soc-clk@25{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcd= r-mask =3D <0x00000040>; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec3_clk: soc-clk@26{ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcd= r-mask =3D <0x00000020>; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}; >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enet0: ethernet@24000 { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...... >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master-clock =3D <&etsec= 1_clk>; >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...... >>> >>> >>> What do you think? > > Quoting your reply: > >> I've avoided requiring clock nodes to have a separate sub node for >> each output because it is more verbose and it prevents clock providers >> from having child nodes for other purposes. =A0Are you concerned that > > I don't see why there should be child nodes for other purposes under cloc= k node. > >> having the <phandle>+output name pair will be difficult to manage? > > That's part of my concern. I was concerned about this too until I found precedence for doing the exact same thing in the pci binding (and ePAPR). Mixing phandle and a string in this way doesn't bother me anymore. > =A0But my main concern is the inability of describing the properties of e= ach clock in the device tree. =A0The clock stuff is much SoC related, which= means it could be variable among chips even in a same family. =A0Having cl= ock properties defined in device tree will make it easier to have an abstra= cted driver to handle clock operations. =A0That's why device trees are used= in the first place, right? You can do whatever you like for your specific clock source driver. All the clock binding provides is a connection from a clock consumer node to a specific named output from a clock provider node. You can add whatever properties (or subnodes) you need for the hardware you are writing a binding for. This binding doesn't prevent you from doing anything. g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Review Request: New proposal for device tree clock binding. 2010-08-09 7:12 ` Grant Likely @ 2010-08-10 4:56 ` Li Yang-R58472 2010-08-10 5:04 ` Grant Likely 0 siblings, 1 reply; 6+ messages in thread From: Li Yang-R58472 @ 2010-08-10 4:56 UTC (permalink / raw) To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr >>> I've avoided requiring clock nodes to have a separate sub node for >>> each output because it is more verbose and it prevents clock >>> providers from having child nodes for other purposes. =A0Are you >>> concerned that >> >> I don't see why there should be child nodes for other purposes under >clock node. >> >>> having the <phandle>+output name pair will be difficult to manage? >> >> That's part of my concern. > >I was concerned about this too until I found precedence for doing the >exact same thing in the pci binding (and ePAPR). Mixing phandle and a >string in this way doesn't bother me anymore. Where exactly can I get the sample code for handling this binding? - Leo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Review Request: New proposal for device tree clock binding. 2010-08-10 4:56 ` Li Yang-R58472 @ 2010-08-10 5:04 ` Grant Likely 0 siblings, 0 replies; 6+ messages in thread From: Grant Likely @ 2010-08-10 5:04 UTC (permalink / raw) To: Li Yang-R58472; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr On Mon, Aug 9, 2010 at 10:56 PM, Li Yang-R58472 <r58472@freescale.com> wrot= e: >>>> I've avoided requiring clock nodes to have a separate sub node for >>>> each output because it is more verbose and it prevents clock >>>> providers from having child nodes for other purposes. =A0Are you >>>> concerned that >>> >>> I don't see why there should be child nodes for other purposes under >>clock node. >>> >>>> having the <phandle>+output name pair will be difficult to manage? >>> >>> That's part of my concern. >> >>I was concerned about this too until I found precedence for doing the >>exact same thing in the pci binding (and ePAPR). =A0Mixing phandle and a >>string in this way doesn't bother me anymore. > > Where exactly can I get the sample code for handling this binding? In my test-devicetree branch. See the file drivers/of/clock.c[1] from commit [2]: [1] http://git.secretlab.ca/?p=3Dlinux-2.6.git;a=3Dblob;f=3Ddrivers/of/cloc= k.c;h=3D26bd70c293d3ec23cbef3f67e0853069b6c24dc0;hb=3Dfadbfb859485148756533= b28203b7b0188a17250 [2] http://git.secretlab.ca/?p=3Dlinux-2.6.git;a=3Dcommit;h=3Dfadbfb8594851= 48756533b28203b7b0188a17250 g. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-08-10 5:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTimm7G--LQHYBqPB1YCXQb7fSXPDaYsLq0p30DG1@mail.gmail.com>
2010-08-09 4:50 ` Review Request: New proposal for device tree clock binding Li Yang-R58472
2010-08-09 5:28 ` Grant Likely
2010-08-09 7:05 ` Li Yang-R58472
2010-08-09 7:12 ` Grant Likely
2010-08-10 4:56 ` Li Yang-R58472
2010-08-10 5:04 ` Grant Likely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).