On 08/01/2013 10:12 AM, Tero Kristo wrote:
On 08/01/2013 05:04 PM, Nishanth Menon wrote:
On 07/31/2013 04:59 AM, Tero Kristo wrote:
On 07/30/2013 09:22 PM, Nishanth Menon wrote:
this patch should be 3/33 to allow dpll.c to build.
On 07/23/2013 02:19 AM, Tero Kristo wrote:
Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.
Looking at the change, I wonder what the rules are for the movement?
commit message was not clear.
This is kind of a merge of almost everything that is needed by clock
drivers at some point. I can move the changes along to the patches that
actually need the exports for clarity and to keep compilation clean.
I think it is better to do in stages (while ensuring compilation is
clean) - it is a bit hard to understand need and context of movement
when a singular movement is done :(
Yep, will do the change for this.
[..]
@@ -356,28 +230,13 @@ unsigned long omap_fixed_divisor_recalc(struct
clk_hw *hw,
/* DPLL Type and DCO Selection Flags */
#define DPLL_J_TYPE 0x1
-long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long
target_rate,
- unsigned long *parent_rate);
-unsigned long omap3_dpll_recalc(struct clk_hw *hw, unsigned long
parent_rate);
-int omap3_noncore_dpll_enable(struct clk_hw *hw);
-void omap3_noncore_dpll_disable(struct clk_hw *hw);
-int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long
rate,
- unsigned long parent_rate);
Why are these being moved to generic?
These are used from the dpll.c by the ops.
The ops should probably move as well from mach-omap2. No reason to keep
it around in mach-omap2 then.
There is reason.... I don't want to move _everything_ from mach-omap2 in
the first phase. But after initial support is in, yes, they can be moved.
I will re-iterate my suggestion again - DPLL enable/disable stuff is
going to be a series of steps, which would not change if we do DT or
non-DT. currently those steps reside inside mach-omap2. having a driver
call into mach-omap2 is counter-intutive, at least to me. if we want to
have a cleanup in the future, mach-omap2 should depend on drivers/clk
rather than the other way around. This is the reason of requesting files
in drivers/clk to be as isolated as possible - dpll operations (the
actual steps) of doing dpll configuration does sound isolated enough to
move into drivers/clk and not have reverse dependencies.
Any reverse dependencies should be clearly mentioned with reasoning why
it cannot be moved in the respective patches, it was a little hard for
me to indicate precisely which functions make absolutely no sense and
which not.
I am not saying this is an easy step to do, but for our future cleanups,
it does sound reasonable to expect from this series.
--
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
