Re: [PATCH v2] clk: check the actual phase if get_phase is provided

From: Shawn Lin
Date: Sun Feb 28 2016 - 20:15:22 EST

On 2016/2/27 8:10, Stephen Boyd wrote:
On 02/26, Shawn Lin wrote:
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@xxxxxxxxxxxxxx>


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

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 ?

Do you have such a platform or driver though? I'd rather not do
anything unless we actually need to.

Currently no, but we going to have one soon in this year which supports
10Â, 20Â, 30Â,... 360Â(each 10Â a step, totally 36 steps). So I look
into phase stuff in advance and send a RFC patch to discuss the
practicability before I actually writing driver code.

I have no idea whether we need it. Or maybe we can just do some tricks
inside current ->set_phase/get_phase call back to meet the requirment.
Otherwiseï I'd rather not add New API either.

Best Regards
Shawn Lin