Messages in this thread | | | Subject | Re: [PATCH v2] clk: check the actual phase if get_phase is provided | From | Shawn Lin <> | Date | Fri, 26 Feb 2016 09:21:56 +0800 |
| |
On 2016/2/26 7:14, Stephen Boyd wrote: > On 02/18, Shawn Lin wrote: >> set_phase does sanity checking of degree and ask sub-driver
[...]
>> already there. >> >> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> >> >> --- > > Knee jerk reaction is why does the provider code set a phase that > isn't requested? Do we need some sort of clk_round_phase() API > that parallels clk_round_rate() so that drivers know what phase > they're going to get? Or do drivers not care what phase they get > when they call clk_set_phase()?
Hi Stephen,
drivers should care what phase they get when calling clk_set_phase(i.e the drivers setting phase to do tuning work should know what the actual degrees is, which is important for them to decide the sample window algorithm).
By looking into the two drivers who use set_phase/get_phase pair currently, they actually both don'e care what the actual degrees when they call clk_set_phase. I think that is because the drivers are used for specific platform which support 0~360 implicitly. But the situation is NOT always right for cross-platform drivers. So add some sort of round_phase API is probably sane ?
>> >> + /* bail early if nothing to do */ >> + if (degrees == clk->core->phase) >> + goto out; >> + > > This could be split out into a different "optimization" patch and > applied today. >
ok, I will split this section into a different patch today.
-- Best Regards Shawn Lin
| |