From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Tomeu Vizoso
<tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Rabin Vincent
<rabin.vincent-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC 0/5] Per-user clock constraints
Date: Fri, 27 Jun 2014 16:30:08 -0600 [thread overview]
Message-ID: <53ADF070.8050002@wwwdotorg.org> (raw)
In-Reply-To: <1403855872-14749-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 06/27/2014 01:57 AM, Tomeu Vizoso wrote:
> Hi,
>
> 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 rate. For now this is limited to setting
> floor and ceiling constraints.
>
> 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. In this first version of the patchset, these functions are
> prepended with two underscores and have the _internal suffix at the end. Mike
> has stated his preference of not prefixing with underscores any public API and
> I agree with him, but we still need a way to distinguish e.g. clk_set_parent()
> in the provider API from that in the consumer API (and from the lock-less
> variant in clk-provider.h!).
The name clk_provider_set_rate would be a good hint that it's an API for
clock providers not consumers.
The name clk_core_set_rate would be a good hint that the function takes
a clk_core object rather than the clk (client) object.
Neither names see too unwieldy to me.
Anyway, that's the color of my bikeshed:-)
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 0/5] Per-user clock constraints
Date: Fri, 27 Jun 2014 16:30:08 -0600 [thread overview]
Message-ID: <53ADF070.8050002@wwwdotorg.org> (raw)
In-Reply-To: <1403855872-14749-1-git-send-email-tomeu.vizoso@collabora.com>
On 06/27/2014 01:57 AM, Tomeu Vizoso wrote:
> Hi,
>
> 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 rate. For now this is limited to setting
> floor and ceiling constraints.
>
> 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. In this first version of the patchset, these functions are
> prepended with two underscores and have the _internal suffix at the end. Mike
> has stated his preference of not prefixing with underscores any public API and
> I agree with him, but we still need a way to distinguish e.g. clk_set_parent()
> in the provider API from that in the consumer API (and from the lock-less
> variant in clk-provider.h!).
The name clk_provider_set_rate would be a good hint that it's an API for
clock providers not consumers.
The name clk_core_set_rate would be a good hint that the function takes
a clk_core object rather than the clk (client) object.
Neither names see too unwieldy to me.
Anyway, that's the color of my bikeshed:-)
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Thierry Reding <thierry.reding@gmail.com>,
Mike Turquette <mturquette@linaro.org>,
Rabin Vincent <rabin.vincent@stericsson.com>,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 0/5] Per-user clock constraints
Date: Fri, 27 Jun 2014 16:30:08 -0600 [thread overview]
Message-ID: <53ADF070.8050002@wwwdotorg.org> (raw)
In-Reply-To: <1403855872-14749-1-git-send-email-tomeu.vizoso@collabora.com>
On 06/27/2014 01:57 AM, Tomeu Vizoso wrote:
> Hi,
>
> 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 rate. For now this is limited to setting
> floor and ceiling constraints.
>
> 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. In this first version of the patchset, these functions are
> prepended with two underscores and have the _internal suffix at the end. Mike
> has stated his preference of not prefixing with underscores any public API and
> I agree with him, but we still need a way to distinguish e.g. clk_set_parent()
> in the provider API from that in the consumer API (and from the lock-less
> variant in clk-provider.h!).
The name clk_provider_set_rate would be a good hint that it's an API for
clock providers not consumers.
The name clk_core_set_rate would be a good hint that the function takes
a clk_core object rather than the clk (client) object.
Neither names see too unwieldy to me.
Anyway, that's the color of my bikeshed:-)
next prev parent reply other threads:[~2014-06-27 22:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-27 7:57 [RFC 0/5] Per-user clock constraints Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
2014-06-27 7:57 ` [RFC 1/5] clk: Add temporary mapping to the existing API Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
2014-06-27 7:57 ` [RFC 3/5] clk: use struct clk only for external API Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
[not found] ` <1403855872-14749-4-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2014-06-27 22:37 ` Stephen Warren
2014-06-27 22:37 ` Stephen Warren
2014-06-27 22:37 ` Stephen Warren
[not found] ` <53ADF239.9050008-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-30 19:43 ` Rabin Vincent
2014-06-30 19:43 ` Rabin Vincent
2014-06-30 19:43 ` Rabin Vincent
2014-06-27 7:57 ` [RFC 4/5] clk: per-user clock accounting for debug Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
2014-06-27 22:44 ` Stephen Warren
2014-06-27 22:44 ` Stephen Warren
[not found] ` <53ADF3C8.2060702-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-06-27 22:51 ` Stephen Warren
2014-06-27 22:51 ` Stephen Warren
2014-06-27 22:51 ` Stephen Warren
2014-06-30 19:49 ` Rabin Vincent
2014-06-30 19:49 ` Rabin Vincent
2014-06-30 19:49 ` Rabin Vincent
[not found] ` <1403855872-14749-1-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2014-06-27 7:57 ` [RFC 2/5] clk: Move all drivers to use internal API Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
2014-06-27 7:57 ` [RFC 5/5] clk: Add floor and ceiling constraints to clock rates Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
2014-06-27 7:57 ` Tomeu Vizoso
[not found] ` <1403855872-14749-6-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2014-06-27 22:57 ` Stephen Warren
2014-06-27 22:57 ` Stephen Warren
2014-06-27 22:57 ` Stephen Warren
2014-06-27 23:10 ` Thierry Reding
2014-06-27 23:10 ` Thierry Reding
2014-07-03 14:02 ` Tomeu Vizoso
2014-07-03 14:02 ` Tomeu Vizoso
2014-06-27 22:30 ` Stephen Warren [this message]
2014-06-27 22:30 ` [RFC 0/5] Per-user clock constraints Stephen Warren
2014-06-27 22:30 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53ADF070.8050002@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=rabin.vincent-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.