On 02/02/2015 11:41 PM, Mike Turquette wrote:
> Quoting Tero Kristo (2015-02-02 11:32:01)
>> On 02/01/2015 11:24 PM, Mike Turquette wrote:
>>> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
>>>> Moves clock state to struct clk_core, but takes care to change as little
>>>> API as
>>>> possible.
>>>>
>>>> struct clk_hw still has a pointer to a struct clk, which is the
>>>> implementation's per-user clk instance, for backwards compatibility.
>>>>
>>>> The struct clk that clk_get_parent() returns isn't owned by the caller,
>>>> but by
>>>> the clock implementation, so the former shouldn't call clk_put() on it.
>>>>
>>>> Because some boards in mach-omap2 still register clocks statically, their
>>>> clock
>>>> registration had to be updated to take into account that the clock
>>>> information
>>>> is stored in struct clk_core now.
>>>
>>> Tero, Paul & Tony,
>>>
>>> Tomeu's patch unveils a problem with omap3_noncore_dpll_enable and
>>> struct dpll_data, namely this snippet from
>>> arch/arm/mach-omap2/dpll3xxx.c:
>>>
>>> parent = __clk_get_parent(hw->clk);
>>>
>>> if (__clk_get_rate(hw->clk) == __clk_get_rate(dd->clk_bypass)) {
>>> WARN(parent != dd->clk_bypass,
>>> "here0, parent name is %s, bypass name is
>>> %s\n",
>>> __clk_get_name(parent),
>>> __clk_get_name(dd->clk_bypass));
>>> r = _omap3_noncore_dpll_bypass(clk);
>>> } else {
>>> WARN(parent != dd->clk_ref,
>>> "here1, parent name is %s, ref name is
>>> %s\n",
>>> __clk_get_name(parent),
>>> __clk_get_name(dd->clk_ref));
>>> r = _omap3_noncore_dpll_lock(clk);
>>> }
>>>
>>> struct dpll_data has members clk_ref and clk_bypass which are struct clk
>>> pointers. This was always a bit of a violation of the clk.h contract
>>> since drivers are not supposed to deref struct clk pointers. Now that we
>>> generate unique pointers for each call to clk_get (clk_ref & clk_bypass
>>> are populated by of_clk_get in ti_clk_register_dpll) then the pointer
>>> comparisons above will never be equal (even if they resolve down to the
>>> same struct clk_core). I added the verbose traces to the WARNs above to
>>> illustrate the point: the names are always the same but the pointers
>>> differ.
>>>
>>> AFAICT this doesn't break anything, but booting on OMAP3+ results in
>>> noisy WARNs.
>>>
>>> I think the correct fix is to replace clk_bypass and clk_ref pointers
>>> with a simple integer parent_index. In fact we already have this index.
>>> See how the pointers are populated in ti_clk_register_dpll:
>>
>> The problem is we still need to be able to get runtime parent clock
>> rates (the parent rate may change also), so simple index value is not
>> sufficient. We need a handle of some sort to the bypass/ref clocks. The
>> DPLL code generally requires knowledge of the bypass + reference clock
>> rates to work properly, as it calculates the M/N values based on these.
>
> We can maybe introduce something like of_clk_get_parent_rate, as we have
> analogous stuff for getting parent names and indexes. Without
> introducing a new helper you could probably just do:
>
> clk_ref = clk_get_parent_by_index(dpll_clk, 0);
> ref_rate = clk_get_rate(clk_ref);
>
> clk_bypass = clk_get_parent_by_index(dpll_clk, 1);
> bypass_rate = clk_get_rate(clk_bypass);
>
> Currently the semantics around this call are weird. It seems like it
> would create a new struct clk pointer but it does not. So don't call
> clk_put on clk_ref and clk_bypass yet. That might change in the future
> as we iron out this brave new world that we all live in. Probably best
> to leave a FIXME in there.
>
> Stephen & Tomeu, let me know if I got any of that wrong.
I think you got it right, just wanted to mention that we can and
probably should make the clk_get_parent_* calls in the consumer API to
return per-user clk instances but that we need to make sure first that
callers call clk_put afterwards.
This should also allow us to remove the reference to struct clk from
clk_hw, which is at best awkward.
Regards,
Tomeu
>>
>> Shall I change the DPLL code to check against clk_hw pointers or what is
>> the preferred approach here? The patch at the end does this and fixes
>> the dpll related warnings.
>
> Yes, for now that is fine, but feels a bit hacky to me. I don't know
> honestly, let me sleep on it. Anyways for 3.20 that is perfectly fine
> but we might want to switch to something like the scheme above.
>
>>
>> Btw, the rate constraints patch broke boot for me completely, but sounds
>> like you reverted it already.
>
> Fixed with Stephen's patch from last week. Thanks for dealing with all
> the breakage so promptly. It has helped a lot!
>
> Regards,
> Mike
>
>>
>> -Tero
>>
>> --------------------
>>
>> Author: Tero Kristo <t-kri...@ti.com>
>> Date: Mon Feb 2 17:19:17 2015 +0200
>>
>> ARM: OMAP3+: clock: dpll: fix logic for comparing parent clocks
>>
>> DPLL code uses reference and bypass clock pointers for determining
>> runtime
>> properties for these clocks, like parent clock rates.
>>
>> As clock API now returns per-user clock structs, using a global handle
>> in the clock driver code does not work properly anymore. Fix this by
>> using the clk_hw instead, and comparing this against the parents.
>>
>> Signed-off-by: Tero Kristo <t-kri...@ti.com>
>> Fixes: 59cf3fcf9baf ("clk: Make clk API return per-user struct clk
>> instances")
>>
>> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
>> index c2da2a0..49752d7 100644
>> --- a/arch/arm/mach-omap2/dpll3xxx.c
>> +++ b/arch/arm/mach-omap2/dpll3xxx.c
>> @@ -410,7 +410,7 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
>> struct clk_hw_omap *clk = to_clk_hw_omap(hw);
>> int r;
>> struct dpll_data *dd;
>> - struct clk *parent;
>> + struct clk_hw *parent;
>>
>> dd = clk->dpll_data;
>> if (!dd)
>> @@ -427,13 +427,13 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
>> }
>> }
>>
>> - parent = __clk_get_parent(hw->clk);
>> + parent = __clk_get_hw(__clk_get_parent(hw->clk));
>>
>> if (__clk_get_rate(hw->clk) == __clk_get_rate(dd->clk_bypass)) {
>> - WARN_ON(parent != dd->clk_bypass);
>> + WARN_ON(parent != __clk_get_hw(dd->clk_bypass));
>> r = _omap3_noncore_dpll_bypass(clk);
>> } else {
>> - WARN_ON(parent != dd->clk_ref);
>> + WARN_ON(parent != __clk_get_hw(dd->clk_ref));
>> r = _omap3_noncore_dpll_lock(clk);
>> }
>>
>> @@ -549,7 +549,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw,
>> unsigned long rate,
>> if (!dd)
>> return -EINVAL;
>>
>> - if (__clk_get_parent(hw->clk) != dd->clk_ref)
>> + if (__clk_get_hw(__clk_get_parent(hw->clk)) !=
>> + __clk_get_hw(dd->clk_ref))
>> return -EINVAL;
>>
>> if (dd->last_rounded_rate == 0)
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
