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

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

[Shawn Lin]

set_phase does sanity checking of degree and ask sub-driver
to set the degree. If set_phase is limited to support the
degree what the caller need, sub-driver may select a
approximate value and return success state. In this case, it's
inappropriate to assign the degree directly to clk->core->phase.
We should ask sub-driver to decide the strategy. If sub-driver just
want to support accurate degree, it can fail the set_phase. Otherwise,
store the actual degree provided by sub-driver into clk->core->phase
if get_phase is provided. Another improvemnt by this patch is that
we can avoid to do unnecessary set_phase if the request defrees is
already there.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>

---

Changes in v2:
- remove actual_degree to simplify the changes
- bail early if nothing to to

 drivers/clk/clk.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b4db67a..275e70f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1902,6 +1902,10 @@ int clk_set_phase(struct clk *clk, int degrees)
 
 	clk_prepare_lock();
 
+	/* bail early if nothing to do */
+	if (degrees == clk->core->phase)
+		goto out;
+
 	trace_clk_set_phase(clk->core, degrees);
 
 	if (clk->core->ops->set_phase)
@@ -1909,9 +1913,13 @@ int clk_set_phase(struct clk *clk, int degrees)
 
 	trace_clk_set_phase_complete(clk->core, degrees);
 
-	if (!ret)
-		clk->core->phase = degrees;
+	if (!ret) {
+		if (clk->core->ops->get_phase)
+			degrees = clk->core->ops->get_phase(clk->core->hw);
 
+		clk->core->phase = degrees;
+	}
+out:
 	clk_prepare_unlock();
 
 	return ret;
-- 
2.3.7

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

[Stephen Boyd]

On 02/18, Shawn Lin wrote:
> set_phase does sanity checking of degree and ask sub-driver
> to set the degree. If set_phase is limited to support the
> degree what the caller need, sub-driver may select a
> approximate value and return success state. In this case, it's
> inappropriate to assign the degree directly to clk->core->phase.
> We should ask sub-driver to decide the strategy. If sub-driver just
> want to support accurate degree, it can fail the set_phase. Otherwise,
> store the actual degree provided by sub-driver into clk->core->phase
> if get_phase is provided. Another improvemnt by this patch is that
> we can avoid to do unnecessary set_phase if the request defrees is
> 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()?

> 
> Changes in v2:
> - remove actual_degree to simplify the changes
> - bail early if nothing to to
> 
>  drivers/clk/clk.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index b4db67a..275e70f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1902,6 +1902,10 @@ int clk_set_phase(struct clk *clk, int degrees)
>  
>  	clk_prepare_lock();
>  
> +	/* 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.

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

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

[Shawn Lin]

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

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

[Stephen Boyd]

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.

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

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