Kevin Hilman said the following on 12/19/2009 04:42 AM:
Nishanth Menon <nm@xxxxxx> writes:
SmartReflex implements a get_opp to search through the opp table,
replace it with the accessor function as it is a duplicate of
freq_to_opp
SmartReflex is not quite working with this version which is in
pm-wip-opp. My (untested) theory below...
[...]
Ambresh and I just tested the very latest of the pm-wip-opp branch and
checked. Voltage transitions and SR adjustments are happily happening on
SDP3430 ES3.1 at the very least (verified with a scope on vdd1).
and if you look closely in the code, sr2.vdd_opp_clk->rate and
sr1.vdd_opp_clk->rate are based on
sr1.vdd_opp_clk = clk_get(NULL, "dpll1_ck")
sr2.vdd_opp_clk = clk_get(NULL, "l3_ick");
now, if the dpll1_ck ->rate and l3_ick->rate are not exact frequencies
as the opp tables, I think we have a clockframework bug and the code
here is correct. we should fix the clockframework/find the rootcause
elsewhere.
Now is the clockframework wrong? we added a patch to print the
frequencies and checked if IS_ERR(opp) is true -> not a single call
while using cpu_freq transitions resulted in an error value and all the
frequencies we printed were from the OPP table
Might be good to hear your rationale for saying this result..
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
