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 >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 >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 >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]. > >==Clock providers== > >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=1 >!property >!format >!notes >|- >|<tt>clock-outputs</tt> >|list of strings >|specifies output clock signal names. >|} > >For example: > > oscillator { > clock-outputs = "ckil", "ckih"; > }; > >- this node defines a device with two clock outputs, the first named >"ckil" and the second named "ckih". Consumer nodes always reference >clocks by name. The names should reflect the clock output signal names >for the device. > >==Clock consumers== > >A device connected to a clock signal needs a *-clock property for each >clock that it is connected to. > >{|border=1 >!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". The property value is a tuple >containing the phandle to the clock provider and the name of the clock output >signal. > >For example: > > uart { > baud-clock = <&osc>, "ckil"; > register-clock = <&ref>, "bus"; > }; > > >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. 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. po...@e0070{ compatible = "fsl,mpc8548-pmc", "fsl,p2020-pmc"; reg = <0xe0070 0x20>; etsec1_clk: soc-...@24{ fsl,pmcdr-mask = <0x00000080>; }; etsec2_clk: soc-...@25{ fsl,pmcdr-mask = <0x00000040>; }; etsec3_clk: soc-...@26{ fsl,pmcdr-mask = <0x00000020>; }; }; enet0: ether...@24000 { ...... master-clock = <&etsec1_clk>; ...... What do you think? - Leo _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev