On 08/01/2013 05:40 PM, Nishanth Menon wrote:
On 07/31/2013 09:52 AM, Tero Kristo wrote:
On 07/30/2013 10:33 PM, Nishanth Menon wrote:
[...]
+ DT_CLK(NULL, "cpufreq_ck", "dpll_mpu_ck"),
please remove cpufreq.
Hmm why?
Because cpufreq is completely broken now and your current work on it? :)
cpufreq fixing can be done separately and has abillity to pick up clock
nodes by describing clocks=<&dpll_mpu_ck> in cpu0 node. absolutely no
need to carry on this hack - See my comment on [1]
yes, I know I will have to redo my cpufreq series, but thanks to your
work, it is a 10 min job to enable them back online :) dont worry about
the broken cpufreq, we will fix it properly and it is not even needed
for basic boot to shell (example omap2plus_defconfig does not even
enable CONFIG_CPU_FREQ).
Ok, I'll drop the cpufreq one out at least. :)
+ abe_dpll_ref = clk_get_sys(NULL, "abe_dpll_refclk_mux_ck");
+ sys_32k_ck = clk_get_sys(NULL, "sys_32k_ck");
+ rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+ abe_dpll = clk_get_sys(NULL, "dpll_abe_ck");
+ if (!rc)
+ rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err("%s: failed to configure ABE DPLL!\n", __func__);
+
+ /*
+ * Lock USB DPLL on OMAP4 devices so that the L3INIT power
+ * domain can transition to retention state when not in use.
+ */
+ usb_dpll = clk_get_sys(NULL, "dpll_usb_ck");
+ rc = clk_set_rate(usb_dpll, OMAP4_DPLL_USB_DEFFREQ);
+ if (rc)
+ pr_err("%s: failed to configure USB DPLL!\n", __func__);
^^^^ why cant we have a generic property that does this "automagically"
from dts property to the node?
a) be able to select a parent
b) be able to set a frequency.
c) how do we ensure that CLK_SET_RATE_PARENT are setup for the clock
nodes defined by dt?
This is probably for Mike to answer, currently such mechanism does not
exist.
I think you already dealt with (c). in the same vein, we can do (a) and
(b). Dont think anyone else has gone about this to the extent we are
attempting to do till date, so as pioneers, we might as well suggest
with a patch :D ?
Yea, for c I have a patch as that is clearly required. For a/b, we can
currently workaround. Again, I don't want to implement everything in
this set at once, as the result would be a huge behemoth (this is
complicated enough as is imo.)
[1] http://marc.info/?l=linux-omap&m=137536714605620&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
