Hi Sylwester, On Thursday 27 March 2014 16:02:52 Sylwester Nawrocki wrote: > On 27/03/14 15:08, Laurent Pinchart wrote: > > On Thursday 27 March 2014 14:57:56 Sylwester Nawrocki wrote: > >> On 27/03/14 14:24, Laurent Pinchart wrote: > >>> On Thursday 27 March 2014 13:16:19 Sylwester Nawrocki wrote: > >>>> This function adds a helper function to configure clock parents and > >>>> rates as specified in clock-parents, clock-rates DT properties for a > >>>> consumer device and a call to it before driver is bound to a device. > >>>> > >>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx> > >>>> --- > >> > >> [...] > >> > >>>> .../devicetree/bindings/clock/clock-bindings.txt | 26 ++++++ > >>>> drivers/base/dd.c | 7 ++ > >>>> drivers/clk/Makefile | 1 + > >>>> drivers/clk/clk-conf.c | 87 ++++++++++++ > >>>> drivers/clk/clk.c | 10 ++- > >>>> include/linux/clk/clk-conf.h | 19 +++++ > >>>> 6 files changed, 149 insertions(+), 1 deletion(-) > >>>> create mode 100644 drivers/clk/clk-conf.c > >>>> create mode 100644 include/linux/clk/clk-conf.h > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt > >>>> b/Documentation/devicetree/bindings/clock/clock-bindings.txt index > >>>> 7c52c29..b452f80 100644 > >>>> --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt > >>>> +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt > >>>> @@ -115,3 +115,29 @@ clock signal, and a UART. > >>>> ("pll" and "pll-switched"). > >>>> > >>>> * The UART has its baud clock connected the external oscillator and > >>>> its register clock connected to the PLL clock (the "pll-switched" > >>>> signal) > >>>> > >>>> + > >>>> +==Assigned clock parents and rates== > >>>> + > >>>> +Some platforms require static initial configuration of parts of the > >>>> clocks > >>>> +controller. Such a configuration can be specified in a clock consumer > >>>> node > >>>> +through clock-parents and clock-rates DT properties. The former should > >>>> contain > >>>> +a list of parent clocks in form of phandle and clock specifier pairs, > >>>> the > >>>> +latter the list of assigned clock frequency values (one cell each). > >>>> + > >>>> + uart@a000 { > >>>> + compatible = "fsl,imx-uart"; > >>>> + reg = <0xa000 0x1000>; > >>>> + ... > >>>> + clocks = <&clkcon 0>, <&clkcon 3>; > >>>> + clock-names = "baud", "mux"; > >>>> + > >>>> + clock-parents = <0>, <&pll 1>; > >>>> + clock-rates = <460800>; > >>>> + }; > >>>> + > >>>> +In this example the pll is set as parent of "mux" clock and frequency > >>>> of "baud" > >>>> +clock is specified as 460800 Hz. > >>> > >>> I'm curious, what should happen when two devices have conflicting > >>> requirements ? If a different device required the <&clkcon 3> parent to > >>> be set to <&pll 2> for instance, who should win ? Shouldn't a warning be > >>> printed ? > >> > >> In general, the assumption is that the <&clkcon 3> clock would be used > >> only by the uart@a000 device. > > > > OK. Removing the problem is a simple way to fix it :-) What about stating > > this explicitly in the documentation then ? Maybe by prefixing your > > proposed explanation below with something like > > > > "Configuring a clock parent and rate through the device node that uses the > > clock is only supported for clocks that have a single user." > > Looks good, we could add it. Or perhaps something like: > > "Configuring a clock parent and rate through the device node that uses the > clock should be only done for clocks that have a single user. If a clock > is shared and conflicting parent or rate configuration is specified in > multiple consumer nodes a resulting configuration is undefined." ? > > Not sure if it is acceptable to inject such an unpredictability to the > kernel from DT though. Might be more reasonable to go with a clarification > as you proposed. I would go further and forbid it. "Configuring a clock parent and rate through the device node that uses the clock can be done only for clocks that have a single user. Specifying conflicting parent or rate configuration in multiple consumer nodes for a shared clock is forbidden." > >> If a clock is shared I'd say it shouldn't be put in a multiple consumer > >> device nodes. Instead it should be put in a clock provider node, as I was > >> trying to explain in the sentence below. > >> > >> A warning could be useful, but it could complicate the code. We would > >> need, for example, to store information about already configured clocks > >> in a list and scan it before actually altering any clock parent or rate. > > > > I'm fine with implementing that later if needed, we can keep the initial > > implementation simple. > > OK. > > >>>> +For clocks which are not directly connected to any consumer device > >>>> similarly > >>>> +clocks, clock-parents and/or clock-rates properties should be > >>>> specified in > >>>> +assigned-clocks subnode of a clock controller DT node. > >>> > >>> It might be that I'm not familiar enough with the clock framework, but > >>> this sounds unclear to me. I'm not sure what you mean exactly. > >> > >> Sorry about not being precise here, would something like below be more > >> clear ? > >> > >> "Configuration of common clocks, which affect multiple consumer devices > >> can be specified in a dedicated 'assigned-clocks' subnode of a clock > >> > >> provider node, e.g.: > >> clkcon { > >> ... > >> #clock-cells = <1>; > >> assigned-clocks { > >> clocks = <&clkcon 16>, <&clkcon 17>; > >> clock-parents = <0>, <&clkcon 1>; > >> clock-rates = <200000>; > >> }; > >> }; > >> " > > > > That's clearer indeed. Can the parents and rates depend on the board, or > > on the SoC only ? We might be getting dangerously close to specifying > > platform configuration instead of describing the hardware. A real example > > might be nice to support the discussion. > > The clock parent and rates could be board specific, otherwise this API would > become much less useful. The configuration often depends on what external > devices are attached to an SoC. > > I don't have a real life example for the "global" configuration of shared > clocks at the moment. I added this after seeing Tero's patches [1], maybe > he could talk about some real use cases (just realized I missed to Cc him. > fixing this mistake now). Sascha has posted a nice example of an assigned-clocks node, let's discuss this in replies to his e-mail. > >> Naturally it's this just an RFC, any critics or suggestions are > >> welcome.:) > > [1] http://www.spinics.net/lists/linux-omap/msg103069.html -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html