Re: moving Tegra30 to the common clock framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 05/08/2012 11:21 PM, Turquette, Mike wrote:
On 20120508-19:20, skannan@xxxxxxxxxxxxxx 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.


Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[ARM Kernel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]     [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux