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

From: Stephen Boyd
Date: Fri Feb 26 2016 - 19:10:49 EST


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
> 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.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project