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

[Shawn Lin]

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