From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Tero Kristo <t-kristo@ti.com>
Cc: Mike Turquette <mturquette@linaro.org>,
Rob Herring <robherring2@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Rob Herring <robh+dt@kernel.org>,
Grant Likely <grant.likely@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Kumar Gala <galak@codeaurora.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Ben Dooks <ben.dooks@codethink.co.uk>,
Peter De Schrijver <pdeschrijver@nvidia.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
sw0312.kim@samsung.com,
Marek Szyprowski <m.szyprowski@samsung.com>,
Tomasz Figa <t.figa@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC v5 2/2] clk: Add handling of clk parent and rate assigned from DT
Date: Fri, 13 Jun 2014 17:06:37 +0200 [thread overview]
Message-ID: <539B137D.4060408@samsung.com> (raw)
In-Reply-To: <537EECC7.2030605@ti.com>
On 23/05/14 08:37, Tero Kristo wrote:
> On 05/23/2014 04:34 AM, Mike Turquette wrote:
[...]
>> It looks like this idea was dropped for v6. Can we revisit it? Take a
>> look at Tero's example implementation for OMAP using this binding:
>>
>> http://www.spinics.net/lists/linux-omap/msg104705.html
>>
>> There is a bogus "default-clocks" node made solely for storing this info
>> within the OMAP PRCM clock provider node. This is basically faking a
>> clock consumer. I think with the proposed solution above Tero could have
>> avoided that node entirely and done the following:
>>
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 649b5cd..e3ff1a7 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -145,6 +145,11 @@
>> cm2_clocks: clocks {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> +
>> + assigned-clocks = <&abe_dpll_refclk_mux_ck>,
>> + <&dpll_usb_ck>, <&dpll_abe_ck>;
>> + assigned-clock-parents = <&sys_32k_ck>;
>> + assigned-clock-rates = <0>, <960000000>, <98304000>;
>> };
>>
>> cm2_clockdomains: clockdomains {
>>
>>
>> Tero, what do you think?
>
> Yeah, if we can avoid having a dummy node someplace, it is always
> better. Only issue might be the initialization order, this was the
> reason I created the dummy node if I recall right. But I guess we can
> just scan the clock provider nodes second time at a later phase of boot
> (or just store the default info for later use.)
One issue I'm a bit concerned about with an initcall-like approach is
it may not work well for clock providers in kernel modules which can be
loaded at any time. So doing the configuration upon the clock provider
registration might have worked better. Then we could disallow (defer)
a clock provider registration if any of its dependencies (as specified
through assigned-clock* properties) are not satisfied. Do you think
that could work ?
--
Thanks,
Sylwester
next prev parent reply other threads:[~2014-06-13 15:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 11:26 [PATCH RFC v5 0/2] clk: Support for DT assigned clock parents and rates Sylwester Nawrocki
2014-04-09 11:26 ` [PATCH RFC v5 1/2] clk: Add function parsing arbitrary clock list DT property Sylwester Nawrocki
2014-04-09 11:26 ` [PATCH RFC v5 2/2] clk: Add handling of clk parent and rate assigned from DT Sylwester Nawrocki
2014-04-10 16:04 ` Rob Herring
2014-04-11 12:25 ` Sylwester Nawrocki
2014-04-11 13:08 ` Laurent Pinchart
2014-05-23 1:34 ` Mike Turquette
2014-05-23 6:37 ` Tero Kristo
2014-06-13 15:06 ` Sylwester Nawrocki [this message]
2014-06-13 14:30 ` Sylwester Nawrocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539B137D.4060408@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=ben.dooks@codethink.co.uk \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=mturquette@linaro.org \
--cc=pdeschrijver@nvidia.com \
--cc=robh+dt@kernel.org \
--cc=robherring2@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=sw0312.kim@samsung.com \
--cc=t-kristo@ti.com \
--cc=t.figa@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox