Re: [PATCH v5 0/6] Per-user clock constraints

From: Tomeu Vizoso
Date: Thu Aug 14 2014 - 08:08:00 EST

On 08/13/2014 11:46 AM, Boris BREZILLON wrote:
Hi Tomeu,

Sorry for the late reply.

On Wed, 6 Aug 2014 15:56:03 +0200
Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> wrote:


in this v5 of the patchset I have just moved the storage of the clock constraints to the struct clk, as suggested by Stephen. Follows the original cover letter blurb:

I'm retaking Rabin's patches [0] for splitting the clk API in two: one API for
clk consumers and another for providers. The consumer API uses a clk structure
that just keeps track of the consumer and has a reference to the actual
clk_core struct, which is used internally.

I have kept a patch from Rabin that aims to aid in debugging nested
enable/disable calls, though my personal aim is to allow more than one consumer
to influence the final, effective frequency rate. For now this is limited to
setting floor and ceiling constraints, with the short-term aim of allowing
devfreq and thermal drivers to set floor and ceiling frequencies on the memory
clock, respectively.

For those functions in the consumer clk API that were called from providers, I
have added variants to clk-provider.h that are the same only that accept a
clk_core instead. These functions are prefixed with clk_provider_.

Patch 1/6 just adds a bunch of defines with the goal of having all the renames
in their own commit while preserving git-bisectability, with patch 3/6
containing the rename itself as generated by the Coccinelle script in [1].
Patch 2/6 is needed because sound/soc/mxs/mxs-saif.c calls both the consumer
and the provider API. The actual implementation of the API split comes in patch
4/6. I will be happy to organize the refactoring differently if anybody has a
better idea.

Patch 5/6 warns when there's an unbalanced usage of the enable and disable
APIs, and patch 6/6 adds the API for setting floor and ceiling frequencies, per

I tested your patch series on an at91 platform (sama5d3), and it works
as expected, but I had to fix some conflicts when applying your patches
on clk-next, and then got a few errors at compile time.

Anyway here is my branch with all those conflicts resolved: [1]. The
last commit [2] fixes the build errors (I'll let you squash/split the
changes as you wish).

Thanks a lot, it has saved me quite some time.

I have just re-run my coccinelle script and added the new file to the input file list. Will be sending v6 now.



Best Regards,



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at