On Sun, Aug 8, 2010 at 10:50 PM, Li Yang-R58472 <r58...@freescale.com> wrote: > It looks like the previous sending didn't hit the mailing list. Resend. > > 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.html 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. 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 > > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
