Thread (18 messages) 18 messages, 4 authors, 2013-03-29

RFC v2: Zynq Clock Controller

From: Stephen Warren <hidden>
Date: 2013-03-25 23:29:48
Also in: linux-devicetree, lkml

On 03/22/2013 04:41 PM, S?ren Brinkmann wrote:
Hi Lars,

On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote:
quoted
On 03/21/2013 12:56 AM, S?ren Brinkmann wrote:
quoted
Hi,

I spent some time working on this and incorporating feedback. Here's an updated proposal for a clock controller for Zynq:

Required properties:
 - #clock-cells : Must be 1
 - compatible : "xlnx,ps7-clkc"  (this may become 'xlnx,zynq-clkc' terminology differs a bit between Xilinx internal and mainline)
 - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
                     (usually 33 MHz oscillators are used for Zynq platforms)
 - clock-output-names : List of strings used to name the clock outputs. Shall be a list of the outputs given below.

Optional properties:
 - clocks : as described in the clock bindings
 - clock-names : as described in the clock bindings

Clock inputs:
The following strings are optional parameters to the 'clock-names' property in
order to provide optional (E)MIO clock sources.
 - swdt_ext_clk
 - gem0_emio_clk
 - gem1_emio_clk
 - mio_clk_XX          # with XX = 00..53

Example:
        clkc: clkc {
                #clock-cells = <1>;
                compatible = "xlnx,ps7-clkc";
                ps-clk-frequency = <33333333>;
The input frequency should be a clock as well.
Again, monolithic vs split. I don't see a reason not to just internally
call clk_register_fixed_rate(). That way its children do not have to
cope with a variable name for the xtal.
Also, with my proposal 'clocks' and 'clock-names' would be purely
optional properties, only required if optional external inputs are
present. Having the xtal defined externally would add mandatory entries for
those props.
But isn't the clock source board-specific? It's a completely separate
object from Zynq's own clock controller HW, and as such should be
represented by a separate DT node, right?

The issue with parent clock names is simply a red herring. A solution is
needed to registered clock with a parent clock object, rather than a
parent clock name. Then, the parent names are completely irrelevant.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help