moving Tegra30 to the common clock framework

Saravana Kannan skannan at codeaurora.org
Wed May 9 20:02:27 EDT 2012


On 05/08/2012 11:21 PM, Turquette, Mike wrote:
> On 20120508-19:20, skannan at codeaurora.org wrote:
>>> It might be beneficial to provide something like a
>>> __clk_reparent_start(new_parent, *scratch_pointer) and
>>> __clk_reparent_finish(*scratch_pointer) if it will be useful for more
>>> than just MSM. Based on this email, I would guess that Tegra would want
>>> something similar too.
>>
>> Thinking more about this, I think this is how any clk op that might change
>> the parent should operate. I will try to write up an RFC patch for this
>> and send it out soon. I'm in a hurry, so will explain more in the RFC
>> patch or in a later email.
>
> I'm interested to see your patch, as I might not be fully understanding
> your requirements.  Is there any reason why making nested calls to
> __clk_prepare and clk_enable from your .set_rate callback isn't enough?
>

Sorry if I wasn't clear -- my plan with the current framework IS to make 
nested (as in, inside the set rate op) calls to __clk_prepare() and 
enable() as needed. But my point is that everyone really wants to do the 
same, so we might as well make it better by putting it in the common 
code and having everyone use it instead of having to redo the same code 
all over the place.

Will send out the patch soon.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.



More information about the linux-arm-kernel mailing list