From: Stephen Boyd <sboyd@codeaurora.org>
To: Mike Turquette <mturquette@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Saravana Kannan <skannan@codeaurora.org>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
Date: Thu, 09 Jan 2014 14:12:05 -0800 [thread overview]
Message-ID: <52CF1EB5.9070706@codeaurora.org> (raw)
In-Reply-To: <52CE055C.5030103@codeaurora.org>
On 01/08/14 18:11, Stephen Boyd wrote:
> On 01/08/14 17:51, Mike Turquette wrote:
>> Patch #3 illustrates the sort of struct-member-creep that worries me.
>> What is to stop someone from putting "unsigned int divider_reg" or
>> "unsigned int mux_reg", and then the thing just keeps growing.
>>
> I see two ways forward if you don't want these members in struct clk_hw.
>
> 1) Inheritance: struct clk_regmap wrapper struct and
> clk_register_regmap() and devm_clk_register_regmap() and then another
> wrapper struct around that.
>
> example:
>
> struct clk_regmap {
> struct clk_hw hw;
> struct regmap *regmap;
> unsigned int enable_reg;
> unsigned int enable_mask;
> bool enable_is_inverted;
> };
>
> struct clk_branch {
> u32 hwcg_reg;
> u32 halt_reg;
> u8 hwcg_bit;
> u8 halt_bit;
> u8 halt_check;
>
> struct clk_regmap clkr;
> };
>
> static struct clk_branch gsbi1_uart_clk = {
> .halt_reg = 0x2fcc,
> .halt_bit = 10,
> .clkr = {
> .enable_reg = 0x29d4,
> .enable_mask = BIT(9),
> .hw.init = &(struct clk_init_data){
> .name = "gsbi1_uart_clk",
> .parent_names = (const char *[]){
> "gsbi1_uart_src",
> },
> .num_parents = 1,
> .ops = &clk_branch_ops,
> .flags = CLK_SET_RATE_PARENT,
> },
> },
> };
The downside to this approach is that we have to have two similar
structs for struct clk_gate if we want to support regmap in that code
path. If we put the regmap inside struct clk_hw we don't have two
different structs, we would just assign different ops.
struct clk_gate {
struct clk_hw hw;
void __iomem *reg;
u8 bit_idx;
u8 flags;
spinlock_t *lock;
};
and
struct clk_gate_regmap {
struct clk_regmap hw;
u8 flags;
spinlock_t *lock;
};
Do you have any preference on which way we move forward here? I have the
wrapper method all finished and ready to send if you agree with that
approach.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
Date: Thu, 09 Jan 2014 14:12:05 -0800 [thread overview]
Message-ID: <52CF1EB5.9070706@codeaurora.org> (raw)
In-Reply-To: <52CE055C.5030103@codeaurora.org>
On 01/08/14 18:11, Stephen Boyd wrote:
> On 01/08/14 17:51, Mike Turquette wrote:
>> Patch #3 illustrates the sort of struct-member-creep that worries me.
>> What is to stop someone from putting "unsigned int divider_reg" or
>> "unsigned int mux_reg", and then the thing just keeps growing.
>>
> I see two ways forward if you don't want these members in struct clk_hw.
>
> 1) Inheritance: struct clk_regmap wrapper struct and
> clk_register_regmap() and devm_clk_register_regmap() and then another
> wrapper struct around that.
>
> example:
>
> struct clk_regmap {
> struct clk_hw hw;
> struct regmap *regmap;
> unsigned int enable_reg;
> unsigned int enable_mask;
> bool enable_is_inverted;
> };
>
> struct clk_branch {
> u32 hwcg_reg;
> u32 halt_reg;
> u8 hwcg_bit;
> u8 halt_bit;
> u8 halt_check;
>
> struct clk_regmap clkr;
> };
>
> static struct clk_branch gsbi1_uart_clk = {
> .halt_reg = 0x2fcc,
> .halt_bit = 10,
> .clkr = {
> .enable_reg = 0x29d4,
> .enable_mask = BIT(9),
> .hw.init = &(struct clk_init_data){
> .name = "gsbi1_uart_clk",
> .parent_names = (const char *[]){
> "gsbi1_uart_src",
> },
> .num_parents = 1,
> .ops = &clk_branch_ops,
> .flags = CLK_SET_RATE_PARENT,
> },
> },
> };
The downside to this approach is that we have to have two similar
structs for struct clk_gate if we want to support regmap in that code
path. If we put the regmap inside struct clk_hw we don't have two
different structs, we would just assign different ops.
struct clk_gate {
struct clk_hw hw;
void __iomem *reg;
u8 bit_idx;
u8 flags;
spinlock_t *lock;
};
and
struct clk_gate_regmap {
struct clk_regmap hw;
u8 flags;
spinlock_t *lock;
};
Do you have any preference on which way we move forward here? I have the
wrapper method all finished and ready to send if you agree with that
approach.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-01-09 22:12 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-24 1:12 [PATCH v4 00/15] Add support for MSM's mmio clock/reset controller Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 01/15] reset: Silence warning in reset-controller.h Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2014-01-06 17:28 ` Philipp Zabel
2014-01-06 17:28 ` Philipp Zabel
2013-12-24 1:12 ` [PATCH v4 02/15] clk: Allow drivers to pass in a regmap Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 13:13 ` Mark Brown
2013-12-24 13:13 ` Mark Brown
2014-01-09 1:51 ` Mike Turquette
2014-01-09 1:51 ` Mike Turquette
2014-01-09 2:11 ` Stephen Boyd
2014-01-09 2:11 ` Stephen Boyd
2014-01-09 22:12 ` Stephen Boyd [this message]
2014-01-09 22:12 ` Stephen Boyd
2014-01-10 5:44 ` Mike Turquette
2014-01-10 5:44 ` Mike Turquette
2014-01-10 7:05 ` Stephen Boyd
2014-01-10 7:05 ` Stephen Boyd
2014-01-14 2:25 ` Stephen Boyd
2014-01-14 2:25 ` Stephen Boyd
2014-01-15 9:28 ` Mike Turquette
2014-01-15 9:28 ` Mike Turquette
2014-01-15 19:03 ` Stephen Boyd
2014-01-15 19:03 ` Stephen Boyd
2014-01-14 3:54 ` Saravana Kannan
2014-01-14 3:54 ` Saravana Kannan
2014-01-15 9:36 ` Mike Turquette
2014-01-15 9:36 ` Mike Turquette
2014-01-15 10:54 ` Mark Brown
2014-01-15 10:54 ` Mark Brown
2014-01-17 1:38 ` Saravana Kannan
2014-01-17 1:38 ` Saravana Kannan
2013-12-24 1:12 ` [PATCH v4 03/15] clk: Add regmap core helpers for enable/disable/is_enabled Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 13:14 ` Mark Brown
2013-12-24 13:14 ` Mark Brown
2013-12-24 15:07 ` Gerhard Sittig
2013-12-24 15:07 ` Gerhard Sittig
2013-12-26 19:31 ` Stephen Boyd
2013-12-26 19:31 ` Stephen Boyd
2013-12-31 13:02 ` Gerhard Sittig
2013-12-31 13:02 ` Gerhard Sittig
2013-12-24 1:12 ` [PATCH v4 04/15] clk: Add set_rate_and_parent() op Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 05/15] clk: qcom: Add support for phase locked loops (PLLs) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 06/15] clk: qcom: Add support for root clock generators (RCGs) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 07/15] clk: qcom: Add support for branches/gate clocks Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 08/15] clk: qcom: Add reset controller support Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 09/15] clk: qcom: Add support for MSM8960's global clock controller (GCC) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 10/15] clk: qcom: Add support for MSM8960's multimedia clock controller (MMCC) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 11/15] clk: qcom: Add support for MSM8974's global clock controller (GCC) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 12/15] clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 13/15] clk: qcom: Add support for MSM8660's global clock controller (GCC) Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 14/15] devicetree: bindings: Document qcom,gcc Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` [PATCH v4 15/15] devicetree: bindings: Document qcom,mmcc Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
2013-12-24 1:12 ` Stephen Boyd
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=52CF1EB5.9070706@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=skannan@codeaurora.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.