On 03/21/2012 12:56 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
* Mark Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> [120321 12:11]:
These aren't new APIs, the clock API has been around since forever.
I disagree. When I say clock API, I mean the actual functions and
their semantics. Not the existence of a header file.
The meaning of clk_enable/disable has been changed and they won't
work without calling clk_prepare/unprepare. So, these are definitely
new APIs. If it weren't new APIs, then none of the general drivers
would need to change.
clk_prepare() and clk_unprepare() are already there for any clk.h user
and are stubbed in no matter what, they're really not a meaningful
barrier here.
Isn't this whole experimental vs non-experimental discussion about the
actual external facing clock APIs and not the platform driver facing APIs?
Sure, prepare/unprepare are already there in the .h file. But they are
stubs and have no impact till we move to the common clock framework or
platforms move to them with their own implementation (certainly not
happening in upstream, so let's leave that part out of this discussion).
So. IMO, for all practical purposes, common clk fwk forces the move to
these new APIs and hence IMO forces the new APIs.
-Saravana
--
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-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
