On 07/31/2013 05:13 AM, Tero Kristo wrote:
On 07/30/2013 09:56 PM, Nishanth Menon wrote:
On 07/23/2013 02:20 AM, Tero Kristo wrote:
OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.
why not extend standard framework to support autoidle capable clocks OR
introduce our own clk node which depends on basic clocks?
Was kind of easier this way.
We never liked taking the easy road :) if we can extend standard
drivers, that will be the first preference - else we will need to
explain precisely why it cant be extended.
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..669d4c4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
Not sure why, at this point in time we are going to calling drivers/clk
code.
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
list_for_each_entry(c, &clk_hw_omap_clocks, node)
if (c->ops && c->ops->allow_idle)
c->ops->allow_idle(c);
+
+ of_omap_clk_allow_autoidle_all();
+
return 0;
}
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
list_for_each_entry(c, &clk_hw_omap_clocks, node)
if (c->ops && c->ops->deny_idle)
c->ops->deny_idle(c);
+
+ of_omap_clk_deny_autoidle_all();
+
these are defined for CONFIG_OF.. anyways, without dt nodes (OMAP3 is
supposed to support non-DT boot even now), this would not work, would it?
The lists are empty so the funcs do nothing. However, dropping CONFIG_OF
would break these of course. Will figure out a fix for this.
The calls are needed for the transition phase until we can move more clk
stuff from mach-omap2 to drivers.
yes please. for ones like these, we can try to maintain a rule of
mach-omap2 calling drivers/clk rather than drivers/clk -> mach-omap2.
This will allow us to move out of mach-omap2 eventually by just deleting
call points in mach-omap2.
[...]
#endif
I personally dont prefer the fact that divider-clock and
fixed-rate-clock now has double meaning - building a multi-arch kernel
for example, this can wreak havoc. standard definitions should not be
monkeyed around with thus if avoidable, and in this case, very much
avoidable.
just my 2 cents.
Yea, as described before, I'll change the code not to make a global
override, instead, just make omap specific override which parses the
extra params. That sound better or still see some issues with that?
I think described above - if we can introduce these into standard
drivers, it is the best, else introduce it with ti, prefix to indicate a
TI variant. keeps everyone happy.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
