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

[Shawn Lin <shawn.lin@rock-chips.com>]

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@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 ?
>>
>
> 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