On 03/16/2012 05:54 PM, Rob Herring wrote:
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
No, please don't do this. This effectively marks the architectures using
the generic clock framework experimental. We can mark drivers as 'you
have been warned', but marking an architecture as experimental is the
wrong sign for both its users and people willing to adopt the framework.
Also we get this:
warning: (ARCH_MX1&& MACH_MX21&& ARCH_MX25&& MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL)
(and no, I don't want to support to clock frameworks in parallel)
+1
For simple users at least, the api is perfectly adequate and it is not
experimental (unless new means experimental).
+1 - not experimental please.
While I agree with Mike and Paul that there is room for a lot of
improvements to the clock APIs, I think the existing APIs in this patch
series can become macro wrappers around any new APIs improvements we add
in the future.
We should have really done that for the
clk_prepare_enable/unprepare_disable(), but it should certainly be
doable for future API additions now that we have the atomic/non-atomic
differentiation out of the way.
Thanks,
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
