Re: [PATCH v13 0/9] Per-user clock constraints
From: Tomeu Vizoso
Date: Wed Sep 24 2014 - 04:27:34 EST
On 09/23/2014 10:59 PM, Stephen Boyd wrote:
> On 09/23/14 11:40, Tomeu Vizoso wrote:
>> this version of the patchset addresses some issues that Russell pointed out
>> * Refactor the changes to clkdev.c to reduce the amount of ifdefs.
>> * Properly release clocks when there isn't enough memory to create the per-user
>> * Add clk_provider_put(struct clk_core*) for clock implementations to call
>> instead of clk_put(struct clk*) (instead of exposing __clk_put).
>> As the previous versions, this is based on top of 3.17-rc4 and Mike's patch at
> Any thoughts on my comments on patch set #10? It seems like we can
> avoid having a flag day to support this.
I cannot say that I fully understand your proposal, but IMO the most
valuable thing in this patchset is precisely the API split (and thus,
the flag day is inherent to it).
I see a lot of value in clk consumers to use a defined set of functions
that all take and/or return struct clk, and for providers to use the
functions that take and/or return struct clk_core. Makes the API clearer
and allows it to have a more scalable growth in the future.
A less important feature of the patchset are per-user clocks, which (if
I understand correctly) your proposal would address without requiring a
And then we have clock constraints, which is probably the least
important feature in the grand scheme of things, but it's actually what
I personally care about.
If we wanted to add a way for clk users to specify clock constraints
without any refactoring, we could easily do so by reusing the request
pattern that pm_qos uses:
void clk_add_constraint(struct clk_request *req,
unsigned long value);
void clk_update_constraint(struct clk_request *req,
unsigned long new_value);
void clk_remove_constraint(struct clk_request *req);
It wouldn't be that bad IMO, but the API refactoring was something that
was long desired and this was seen as a good opportunity to tackle it
before it gets worst.
>  https://lkml.org/lkml/2014/9/9/960
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/