From: Saravana Kannan <skannan@codeaurora.org> To: "Turquette, Mike" <mturquette@ti.com> Cc: Sascha Hauer <s.hauer@pengutronix.de>, Andrew Lunn <andrew@lunn.ch>, Grant Likely <grant.likely@secretlab.ca>, Jamie Iles <jamie@jamieiles.com>, Jeremy Kerr <jeremy.kerr@canonical.com>, Magnus Damm <magnus.damm@gmail.com>, Deepak Saxena <dsaxena@linaro.org>, linux-arm-kernel@lists.infradead.org, Arnd Bergman <arnd.bergmann@linaro.org>, linux-arm-msm@vger.kernel.org, Rob Herring <rob.herring@calxeda.com>, Russell King <linux@arm.linux.org.uk>, Thomas Gleixner <tglx@linutronix.de>, Richard Zhao <richard.zhao@linaro.org>, Shawn Guo <shawn.guo@freescale.com>, Paul Walmsley <paul@pwsan.com>, Linus Walleij <linus.walleij@stericsson.com>, Mark Brown <broonie@opensource.wolfsonmicro.com>, Stephen Boyd <sboyd@codeaurora.org>, linux-kernel@vger.kernel.org, Amit Kucheria <amit.kucheria@linaro.org>, Shawn Guo <shawn.guo@linaro.org> Subject: Re: [PATCH 2/2] clk: Move init fields from clk to clk_hw Date: Tue, 20 Mar 2012 20:01:24 -0700 [thread overview] Message-ID: <4F694484.1030706@codeaurora.org> (raw) In-Reply-To: <CAJOA=zOGTW7OqACWgJQW6HSPLVev+apdNhv4vNXjHTcp=7N+uQ@mail.gmail.com> On 03/20/2012 06:47 PM, Turquette, Mike wrote: > On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de> wrote: >> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote: >>> On 03/20/2012 11:10 AM, Sascha Hauer wrote: >>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote: >>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote: >>>>> ... >>>>>> I am using these functions and don't need a static array, I just call >>>>>> the functions with the desired parameters. >>>>>> >>>>> With this patch getting in, you do not have to use them then. I feel >>>>> a static array will be much more readable than a long list of function >>>>> calls with a long list of hardcoded arguments to each. >>>> >>>> I'm also not a fan of long argument lists; a divider like defined in my >>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the >>>> border I think it's still acceptable. >>>> >>>> What I like in terms of readability is one line per clock which makes >>>> for quite short clock files. >>> >>> It certainly makes for short clock files, but it's definitely less >>> readable that the expanded struct. For the original author the "one >>> line per clock" looks readable since they wrote it. But for someone >>> looking at the code to modify it, the expanded one would be much >>> easier to read. Also, you can always declare your own macro if you >>> really want to follow the one line approach. >>> >>>> So when we use structs to initialize the clocks we'll probably have >>>> something like this: >>>> >>>> static struct clk_divider somediv = { >>>> .reg = CCM_BASE + 0x14, >>>> .width = 3, >>>> .shift = 17, >>>> .lock =&ccm_lock, >>>> .hw.parent = "someotherdiv", >>>> .hw.flags = CLK_SET_RATE_PARENT, >>>> }; >>> >>> Taken from your patches: >>> >>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks, >>> ARRAY_SIZE(spll_sel_clks)); >>> >>> Compare the struct to the one line call. Now tell me, what does "1" >>> represent? No clue. But in the struct, I can immediately tell what >>> each one of the parameters are. >>> >>> Anyway, my patch certainly isn't forcing you to use multiple lines. >>> So, hopefully this won't be a point of contention. >>> >>>> This will make a 4000 line file out of a 500 line file. Now when for >>>> some reason struct clk_divider changes we end with big patches. If the >>>> clk core gets a new fancy CLK_ flag which we want to have then again >>>> we end up with big patches. Then there's also the possibility that >>>> someone finds out that .lock and .hw.flags are common to all dividers >>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common >>>> fields. >>> >>> This patch won't prevent you from doing any of that. You can still >>> create macros for that (there are already one for that). Also, what >>> you are pointing out is a bigger problem for the current >>> clk_register() function since you might have to change the no. of >>> params of all the callers even if a new field is optional. >>> >>>> All this can be solved when we introduce a small wrapper function and >>>> use it in the clock files: >>>> >>>> static inline struct clk *imx_clk_divider(const char *name, const char *parent, >>>> void __iomem *reg, u8 shift, u8 width) >>>> { >>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT, >>>> reg, shift, width, 0,&imx_ccm_lock); >>>> } >>>> >>>> It decouples us from the structs used by the clock framework, we can >>>> add our preferred flags and still can share common fields like the lock. >>>> >>>> While this was not the intention when I first converted from struct >>>> initializers to function initializers I am confident that it will make >>>> a good job. >>> >>> Now I'm confused -- it's not clear if you are leaning towards my >>> patch or away from it? >> >> There was a tendency to get rid of static initializers and I like the >> idea of not exposing any of the internally used members outside the >> clock framework. > > I'm with Sascha on this. I feel that dividing the interface strictly > into two halves is the best way. I addressed this concern in my earlier comments. We can make a copy or we can agree the fields I moved to clk_hw aren't really useful wrt writing hacky code and call it a day. Can you please clarify why neither of these options are acceptable? > I have an uneasy feeling about > exposing this stuff into struct clk_hw (or clk_initializer or > whatever). This stretches the data out across three structures and > just doesn't feel right to me. Wrt this discussion, there are three distinct classes of data: 1) Those specific to the platform driver that the common code shouldn't care about. 2) Those specific to the common code that the platform driver shouldn't care about. 3) Stuff that's shared/passed between common code and the platform driver. When we have three classes of data, I don't what's wrong with having three struct types to contain them. If anything, it's better than the current approach of exposing the common clock code specific data (struct clk) to code outside of common clock code just because we want to allow static initialization. The end goal should be to move struct clk inside clk.c. I think this patch just takes us one step close to that since IMX and MSM won't have to include clk-private.h in any of our platform specific files while also allowing OMAP to include it for the near term. >> Now people try their best to make themselves comfortable with the >> static initializers and you even discussed the possibility of removing >> the clk_register_* functions (which make it possible for users not >> to use any of the internal struct members). That's what I don't like >> about your patches. But if we go for static initializers anyway then your >> patches probably change things for the better. > > Static initialization is something I have fought for; in fact the > original patches provided no way to do it, so clearly what we have > today is some progress for the folks desiring static init. I too desire static init. Sorry if I was unclear and gave people the misconception that I wanted to remove static init. > The patch > above doesn't actually prevent allocation from happening as it still > must call into clk_register and kmalloc struct clk, Correct. > so besides > readability, I'm not sure what these patches buy us. I think readability is very important and if this buys us nothing but readability, we should still take this patch. But there are other benefits too -- I mentioned them in the commit text. > Assuming that C99 designated initializers (for the sole purpose of > readability) is the main draw of the above patch, please let me know > what you think about modifying the existing static init macros so that > your clock data looks like this: > > DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck", > .flags = 0x0, > .reg = OMAP4430_CM_DIV_M5_DPLL_IVA, > .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT, > .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH, > .flags = CLK_DIVIDER_ONE_BASED, > .lock = NULL > ); > > Note that the first argument is the name of this clock (and will be > properly stringified for .name = "whatever") and that the second and > third arguments are both the parent clock, used for initializing the > parent pointer and .parent_names, respectively. If that aspect of the > macro is too ugly then those can even be broken out into a separate > macro since they are independent data structure (struct clk **parents, > and char **parent_names). Or you could just open code those data > structures and only use a macro for struct clk and struct clk_foo. > > This gives you the readability of C99 designated initializers while > keeping struct clk's members totally hidden from the rest of the > world. But it still leaves the struct clk exposed to people who do static init of the clock tree. I think agreeing that the name, parent names, flags and ops are not used to hack with or just making a copy of all of them (and mark the originals as __init if that's doable). is a better solution than trying to go with macros and leave struct clk exposed to everyone who want to do static init of the clock tree. At a later point when we are ready to move struct clk inside clk.c, with this patch applied right now, IMX and MSM won't have to churn their code. 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.
WARNING: multiple messages have this Message-ID (diff)
From: skannan@codeaurora.org (Saravana Kannan) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/2] clk: Move init fields from clk to clk_hw Date: Tue, 20 Mar 2012 20:01:24 -0700 [thread overview] Message-ID: <4F694484.1030706@codeaurora.org> (raw) In-Reply-To: <CAJOA=zOGTW7OqACWgJQW6HSPLVev+apdNhv4vNXjHTcp=7N+uQ@mail.gmail.com> On 03/20/2012 06:47 PM, Turquette, Mike wrote: > On Tue, Mar 20, 2012 at 4:12 PM, Sascha Hauer<s.hauer@pengutronix.de> wrote: >> On Tue, Mar 20, 2012 at 01:06:34PM -0700, Saravana Kannan wrote: >>> On 03/20/2012 11:10 AM, Sascha Hauer wrote: >>>> On Tue, Mar 20, 2012 at 10:18:14PM +0800, Shawn Guo wrote: >>>>> On Tue, Mar 20, 2012 at 10:40:31AM +0100, Sascha Hauer wrote: >>>>> ... >>>>>> I am using these functions and don't need a static array, I just call >>>>>> the functions with the desired parameters. >>>>>> >>>>> With this patch getting in, you do not have to use them then. I feel >>>>> a static array will be much more readable than a long list of function >>>>> calls with a long list of hardcoded arguments to each. >>>> >>>> I'm also not a fan of long argument lists; a divider like defined in my >>>> tree takes 5 arguments, a gate 4 and a mux 6. While 6 is already at the >>>> border I think it's still acceptable. >>>> >>>> What I like in terms of readability is one line per clock which makes >>>> for quite short clock files. >>> >>> It certainly makes for short clock files, but it's definitely less >>> readable that the expanded struct. For the original author the "one >>> line per clock" looks readable since they wrote it. But for someone >>> looking at the code to modify it, the expanded one would be much >>> easier to read. Also, you can always declare your own macro if you >>> really want to follow the one line approach. >>> >>>> So when we use structs to initialize the clocks we'll probably have >>>> something like this: >>>> >>>> static struct clk_divider somediv = { >>>> .reg = CCM_BASE + 0x14, >>>> .width = 3, >>>> .shift = 17, >>>> .lock =&ccm_lock, >>>> .hw.parent = "someotherdiv", >>>> .hw.flags = CLK_SET_RATE_PARENT, >>>> }; >>> >>> Taken from your patches: >>> >>> imx_clk_mux("spll_sel", CCM_CSCR, 17, 1, spll_sel_clks, >>> ARRAY_SIZE(spll_sel_clks)); >>> >>> Compare the struct to the one line call. Now tell me, what does "1" >>> represent? No clue. But in the struct, I can immediately tell what >>> each one of the parameters are. >>> >>> Anyway, my patch certainly isn't forcing you to use multiple lines. >>> So, hopefully this won't be a point of contention. >>> >>>> This will make a 4000 line file out of a 500 line file. Now when for >>>> some reason struct clk_divider changes we end with big patches. If the >>>> clk core gets a new fancy CLK_ flag which we want to have then again >>>> we end up with big patches. Then there's also the possibility that >>>> someone finds out that .lock and .hw.flags are common to all dividers >>>> and comes up with a #define DEFINE_CLK_DIVIDER again to share common >>>> fields. >>> >>> This patch won't prevent you from doing any of that. You can still >>> create macros for that (there are already one for that). Also, what >>> you are pointing out is a bigger problem for the current >>> clk_register() function since you might have to change the no. of >>> params of all the callers even if a new field is optional. >>> >>>> All this can be solved when we introduce a small wrapper function and >>>> use it in the clock files: >>>> >>>> static inline struct clk *imx_clk_divider(const char *name, const char *parent, >>>> void __iomem *reg, u8 shift, u8 width) >>>> { >>>> return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT, >>>> reg, shift, width, 0,&imx_ccm_lock); >>>> } >>>> >>>> It decouples us from the structs used by the clock framework, we can >>>> add our preferred flags and still can share common fields like the lock. >>>> >>>> While this was not the intention when I first converted from struct >>>> initializers to function initializers I am confident that it will make >>>> a good job. >>> >>> Now I'm confused -- it's not clear if you are leaning towards my >>> patch or away from it? >> >> There was a tendency to get rid of static initializers and I like the >> idea of not exposing any of the internally used members outside the >> clock framework. > > I'm with Sascha on this. I feel that dividing the interface strictly > into two halves is the best way. I addressed this concern in my earlier comments. We can make a copy or we can agree the fields I moved to clk_hw aren't really useful wrt writing hacky code and call it a day. Can you please clarify why neither of these options are acceptable? > I have an uneasy feeling about > exposing this stuff into struct clk_hw (or clk_initializer or > whatever). This stretches the data out across three structures and > just doesn't feel right to me. Wrt this discussion, there are three distinct classes of data: 1) Those specific to the platform driver that the common code shouldn't care about. 2) Those specific to the common code that the platform driver shouldn't care about. 3) Stuff that's shared/passed between common code and the platform driver. When we have three classes of data, I don't what's wrong with having three struct types to contain them. If anything, it's better than the current approach of exposing the common clock code specific data (struct clk) to code outside of common clock code just because we want to allow static initialization. The end goal should be to move struct clk inside clk.c. I think this patch just takes us one step close to that since IMX and MSM won't have to include clk-private.h in any of our platform specific files while also allowing OMAP to include it for the near term. >> Now people try their best to make themselves comfortable with the >> static initializers and you even discussed the possibility of removing >> the clk_register_* functions (which make it possible for users not >> to use any of the internal struct members). That's what I don't like >> about your patches. But if we go for static initializers anyway then your >> patches probably change things for the better. > > Static initialization is something I have fought for; in fact the > original patches provided no way to do it, so clearly what we have > today is some progress for the folks desiring static init. I too desire static init. Sorry if I was unclear and gave people the misconception that I wanted to remove static init. > The patch > above doesn't actually prevent allocation from happening as it still > must call into clk_register and kmalloc struct clk, Correct. > so besides > readability, I'm not sure what these patches buy us. I think readability is very important and if this buys us nothing but readability, we should still take this patch. But there are other benefits too -- I mentioned them in the commit text. > Assuming that C99 designated initializers (for the sole purpose of > readability) is the main draw of the above patch, please let me know > what you think about modifying the existing static init macros so that > your clock data looks like this: > > DEFINE_CLK_DIVIDER(dpll_iva_m5x2_ck,&dpll_iva_x2_ck, "dpll_iva_x2_ck", > .flags = 0x0, > .reg = OMAP4430_CM_DIV_M5_DPLL_IVA, > .shift = OMAP4430_HSDIVIDER_CLKOUT2_DIV_SHIFT, > .width = OMAP4430_HSDIVIDER_CLKOUT2_DIV_WIDTH, > .flags = CLK_DIVIDER_ONE_BASED, > .lock = NULL > ); > > Note that the first argument is the name of this clock (and will be > properly stringified for .name = "whatever") and that the second and > third arguments are both the parent clock, used for initializing the > parent pointer and .parent_names, respectively. If that aspect of the > macro is too ugly then those can even be broken out into a separate > macro since they are independent data structure (struct clk **parents, > and char **parent_names). Or you could just open code those data > structures and only use a macro for struct clk and struct clk_foo. > > This gives you the readability of C99 designated initializers while > keeping struct clk's members totally hidden from the rest of the > world. But it still leaves the struct clk exposed to people who do static init of the clock tree. I think agreeing that the name, parent names, flags and ops are not used to hack with or just making a copy of all of them (and mark the originals as __init if that's doable). is a better solution than trying to go with macros and leave struct clk exposed to everyone who want to do static init of the clock tree. At a later point when we are ready to move struct clk inside clk.c, with this patch applied right now, IMX and MSM won't have to churn their code. 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.
next prev parent reply other threads:[~2012-03-21 3:01 UTC|newest] Thread overview: 242+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-16 6:11 [PATCH v7 0/3] common clk framework Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-16 6:11 ` [PATCH v7 1/3] Documentation: common clk API Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-16 8:25 ` Linus Walleij 2012-03-16 8:25 ` Linus Walleij 2012-03-16 10:29 ` Thomas Gleixner 2012-03-16 10:29 ` Thomas Gleixner 2012-03-16 11:14 ` Amit Kucheria 2012-03-16 11:14 ` Amit Kucheria 2012-03-16 12:18 ` Arnd Bergmann 2012-03-16 12:18 ` Arnd Bergmann 2012-03-16 20:57 ` Arnd Bergmann 2012-03-16 20:57 ` Arnd Bergmann 2012-03-16 21:40 ` Turquette, Mike 2012-03-16 21:40 ` Turquette, Mike 2012-03-16 21:50 ` Nicolas Pitre 2012-03-16 21:50 ` Nicolas Pitre 2012-03-16 22:21 ` Paul Walmsley 2012-03-16 22:21 ` Paul Walmsley 2012-03-16 22:21 ` Paul Walmsley 2012-03-16 22:33 ` Turquette, Mike 2012-03-16 22:33 ` Turquette, Mike 2012-03-17 9:05 ` Arnd Bergmann 2012-03-17 9:05 ` Arnd Bergmann 2012-03-17 9:05 ` Arnd Bergmann 2012-03-17 18:02 ` Turquette, Mike 2012-03-17 18:02 ` Turquette, Mike 2012-03-17 18:02 ` Turquette, Mike 2012-03-17 18:33 ` Arnd Bergmann 2012-03-17 18:33 ` Arnd Bergmann 2012-03-17 18:33 ` Arnd Bergmann 2012-03-17 20:29 ` Sascha Hauer 2012-03-17 20:29 ` Sascha Hauer 2012-03-17 20:29 ` Sascha Hauer 2012-03-17 21:13 ` Arnd Bergmann 2012-03-17 21:13 ` Arnd Bergmann 2012-03-17 21:13 ` Arnd Bergmann 2012-03-20 23:40 ` Paul Walmsley 2012-03-20 23:40 ` Paul Walmsley 2012-03-21 8:59 ` Arnd Bergmann 2012-03-21 8:59 ` Arnd Bergmann 2012-03-16 23:47 ` Sascha Hauer 2012-03-16 23:47 ` Sascha Hauer 2012-03-16 23:47 ` Sascha Hauer 2012-03-17 0:54 ` Rob Herring 2012-03-17 0:54 ` Rob Herring 2012-03-17 0:54 ` Rob Herring 2012-03-17 3:38 ` Saravana Kannan 2012-03-17 3:38 ` Saravana Kannan 2012-03-17 3:38 ` Saravana Kannan 2012-03-20 23:31 ` Paul Walmsley 2012-03-20 23:31 ` Paul Walmsley 2012-03-20 23:31 ` Paul Walmsley 2012-03-21 3:15 ` Nicolas Pitre 2012-03-21 3:15 ` Nicolas Pitre 2012-03-21 3:15 ` Nicolas Pitre 2012-03-21 3:26 ` Saravana Kannan 2012-03-21 3:26 ` Saravana Kannan 2012-03-21 3:26 ` Saravana Kannan 2012-03-21 7:44 ` Paul Walmsley 2012-03-21 7:44 ` Paul Walmsley 2012-03-21 7:44 ` Paul Walmsley 2012-03-21 9:10 ` Sascha Hauer 2012-03-21 9:10 ` Sascha Hauer 2012-03-21 9:10 ` Sascha Hauer 2012-03-21 18:38 ` Saravana Kannan 2012-03-21 18:38 ` Saravana Kannan 2012-03-21 18:38 ` Saravana Kannan 2012-03-21 19:07 ` Mark Brown 2012-03-21 19:07 ` Mark Brown 2012-03-21 19:07 ` Mark Brown 2012-03-21 19:33 ` Tony Lindgren 2012-03-21 19:33 ` Tony Lindgren 2012-03-21 19:33 ` Tony Lindgren 2012-03-21 19:41 ` Saravana Kannan 2012-03-21 19:41 ` Saravana Kannan 2012-03-21 19:41 ` Saravana Kannan 2012-03-21 19:56 ` Mark Brown 2012-03-21 19:56 ` Mark Brown 2012-03-21 19:56 ` Mark Brown 2012-03-21 20:04 ` Saravana Kannan 2012-03-21 20:04 ` Saravana Kannan 2012-03-21 20:04 ` Saravana Kannan 2012-03-21 20:10 ` Mark Brown 2012-03-21 20:10 ` Mark Brown 2012-03-21 20:10 ` Mark Brown 2012-03-22 0:42 ` Russell King - ARM Linux 2012-03-22 0:42 ` Russell King - ARM Linux 2012-03-22 0:42 ` Russell King - ARM Linux 2012-03-21 7:30 ` Paul Walmsley 2012-03-21 7:30 ` Paul Walmsley 2012-03-21 7:30 ` Paul Walmsley 2012-03-21 13:23 ` Nicolas Pitre 2012-03-21 13:23 ` Nicolas Pitre 2012-03-21 13:23 ` Nicolas Pitre 2012-03-16 6:11 ` [PATCH v7 2/3] clk: introduce the common clock framework Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-17 3:28 ` Saravana Kannan 2012-03-17 3:28 ` Saravana Kannan 2012-03-19 18:56 ` Turquette, Mike 2012-03-19 18:56 ` Turquette, Mike 2012-03-19 19:13 ` Saravana Kannan 2012-03-19 19:13 ` Saravana Kannan 2012-03-19 19:33 ` Turquette, Mike 2012-03-19 19:33 ` Turquette, Mike 2012-03-19 19:49 ` Saravana Kannan 2012-03-19 19:49 ` Saravana Kannan 2012-03-20 3:38 ` [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn Saravana Kannan 2012-03-20 3:38 ` Saravana Kannan 2012-03-20 3:38 ` [PATCH 2/2] clk: Move init fields from clk to clk_hw Saravana Kannan 2012-03-20 3:38 ` Saravana Kannan 2012-03-20 7:20 ` Shawn Guo 2012-03-20 7:20 ` Shawn Guo 2012-03-20 7:54 ` Saravana Kannan 2012-03-20 7:54 ` Saravana Kannan 2012-03-20 7:54 ` Saravana Kannan 2012-03-20 8:13 ` Shawn Guo 2012-03-20 8:13 ` Shawn Guo 2012-03-20 9:40 ` Sascha Hauer 2012-03-20 9:40 ` Sascha Hauer 2012-03-20 10:17 ` Saravana Kannan 2012-03-20 10:17 ` Saravana Kannan 2012-03-20 10:17 ` Saravana Kannan 2012-03-20 18:14 ` Sascha Hauer 2012-03-20 18:14 ` Sascha Hauer 2012-03-20 20:14 ` Saravana Kannan 2012-03-20 20:14 ` Saravana Kannan 2012-03-20 22:40 ` Sascha Hauer 2012-03-20 22:40 ` Sascha Hauer 2012-03-22 3:23 ` Shawn Guo 2012-03-22 3:23 ` Shawn Guo 2012-03-20 14:18 ` Shawn Guo 2012-03-20 14:18 ` Shawn Guo 2012-03-20 18:10 ` Sascha Hauer 2012-03-20 18:10 ` Sascha Hauer 2012-03-20 20:06 ` Saravana Kannan 2012-03-20 20:06 ` Saravana Kannan 2012-03-20 23:12 ` Sascha Hauer 2012-03-20 23:12 ` Sascha Hauer 2012-03-21 1:47 ` Turquette, Mike 2012-03-21 1:47 ` Turquette, Mike 2012-03-21 3:01 ` Saravana Kannan [this message] 2012-03-21 3:01 ` Saravana Kannan 2012-03-27 4:35 ` Saravana Kannan 2012-03-27 4:35 ` Saravana Kannan 2012-03-27 18:49 ` Turquette, Mike 2012-03-27 18:49 ` Turquette, Mike 2012-03-27 22:27 ` Saravana Kannan 2012-03-27 22:27 ` Saravana Kannan 2012-04-06 1:30 ` Saravana Kannan 2012-04-06 1:30 ` Saravana Kannan 2012-04-11 17:59 ` Turquette, Mike 2012-04-11 17:59 ` Turquette, Mike 2012-04-11 19:57 ` Saravana Kannan 2012-04-11 19:57 ` Saravana Kannan 2012-04-11 19:57 ` Saravana Kannan 2012-04-11 20:17 ` Turquette, Mike 2012-04-11 20:17 ` Turquette, Mike 2012-04-11 20:21 ` Saravana Kannan 2012-04-11 20:21 ` Saravana Kannan 2012-04-11 20:21 ` Saravana Kannan 2012-03-20 23:47 ` Paul Walmsley 2012-03-20 23:47 ` Paul Walmsley 2012-03-21 9:16 ` Sascha Hauer 2012-03-21 9:16 ` Sascha Hauer 2012-03-20 7:19 ` [PATCH 1/2] clk: Fix error handling in fixed clock hardware type register fn Sascha Hauer 2012-03-20 7:19 ` Sascha Hauer 2012-03-20 7:46 ` Saravana Kannan 2012-03-20 7:46 ` Saravana Kannan 2012-03-20 7:46 ` Saravana Kannan 2012-03-21 0:13 ` Turquette, Mike 2012-03-21 0:13 ` Turquette, Mike 2012-03-21 2:32 ` Saravana Kannan 2012-03-21 2:32 ` Saravana Kannan 2012-03-21 5:45 ` Turquette, Mike 2012-03-21 5:45 ` Turquette, Mike 2012-03-21 6:33 ` Saravana Kannan 2012-03-21 6:33 ` Saravana Kannan 2012-03-21 6:33 ` Saravana Kannan 2012-03-21 9:07 ` Russell King - ARM Linux 2012-03-21 9:07 ` Russell King - ARM Linux 2012-03-21 19:56 ` Turquette, Mike 2012-03-21 19:56 ` Turquette, Mike 2012-03-18 13:46 ` [PATCH v7 2/3] clk: introduce the common clock framework Shawn Guo 2012-03-18 13:46 ` Shawn Guo 2012-03-19 18:58 ` Turquette, Mike 2012-03-19 18:58 ` Turquette, Mike 2012-03-18 14:07 ` Shawn Guo 2012-03-18 14:07 ` Shawn Guo 2012-03-19 19:00 ` Turquette, Mike 2012-03-19 19:00 ` Turquette, Mike 2012-03-19 11:22 ` Rajendra Nayak 2012-03-19 11:22 ` Rajendra Nayak 2012-03-19 11:28 ` Sascha Hauer 2012-03-19 11:28 ` Sascha Hauer 2012-03-19 19:09 ` Turquette, Mike 2012-03-19 19:09 ` Turquette, Mike 2012-03-19 19:53 ` Turquette, Mike 2012-03-19 19:53 ` Turquette, Mike 2012-03-20 14:02 ` Shawn Guo 2012-03-20 14:02 ` Shawn Guo 2012-03-20 17:46 ` Saravana Kannan 2012-03-20 17:46 ` Saravana Kannan 2012-03-20 23:53 ` Turquette, Mike 2012-03-20 23:53 ` Turquette, Mike 2012-03-21 3:10 ` Saravana Kannan 2012-03-21 3:10 ` Saravana Kannan 2012-03-23 21:33 ` Saravana Kannan 2012-03-23 21:33 ` Saravana Kannan 2012-03-23 21:39 ` Turquette, Mike 2012-03-23 21:39 ` Turquette, Mike 2012-03-23 21:51 ` Saravana Kannan 2012-03-23 21:51 ` Saravana Kannan 2012-03-23 22:12 ` Saravana Kannan 2012-03-23 22:12 ` Saravana Kannan 2012-03-23 22:32 ` Turquette, Mike 2012-03-23 22:32 ` Turquette, Mike 2012-03-23 23:04 ` Saravana Kannan 2012-03-23 23:04 ` Saravana Kannan 2012-03-23 23:28 ` Turquette, Mike 2012-03-23 23:28 ` Turquette, Mike 2012-03-28 3:06 ` Saravana Kannan 2012-03-28 3:06 ` Saravana Kannan 2012-03-28 17:08 ` Turquette, Mike 2012-03-28 17:08 ` Turquette, Mike 2012-03-28 22:25 ` Saravana Kannan 2012-03-28 22:25 ` Saravana Kannan 2012-03-28 23:49 ` Turquette, Mike 2012-03-28 23:49 ` Turquette, Mike 2012-03-20 23:46 ` Turquette, Mike 2012-03-20 23:46 ` Turquette, Mike 2012-03-21 5:46 ` Shawn Guo 2012-03-21 5:46 ` Shawn Guo 2012-03-16 6:11 ` [PATCH v7 3/3] clk: basic clock hardware types Mike Turquette 2012-03-16 6:11 ` Mike Turquette 2012-03-16 12:25 ` Richard Zhao 2012-03-16 12:25 ` Richard Zhao 2012-03-16 16:51 ` Turquette, Mike 2012-03-16 16:51 ` Turquette, Mike 2012-03-16 10:57 ` [PATCH v7 0/3] common clk framework Sascha Hauer 2012-03-16 10:57 ` Sascha Hauer
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=4F694484.1030706@codeaurora.org \ --to=skannan@codeaurora.org \ --cc=amit.kucheria@linaro.org \ --cc=andrew@lunn.ch \ --cc=arnd.bergmann@linaro.org \ --cc=broonie@opensource.wolfsonmicro.com \ --cc=dsaxena@linaro.org \ --cc=grant.likely@secretlab.ca \ --cc=jamie@jamieiles.com \ --cc=jeremy.kerr@canonical.com \ --cc=linus.walleij@stericsson.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=magnus.damm@gmail.com \ --cc=mturquette@ti.com \ --cc=paul@pwsan.com \ --cc=richard.zhao@linaro.org \ --cc=rob.herring@calxeda.com \ --cc=s.hauer@pengutronix.de \ --cc=sboyd@codeaurora.org \ --cc=shawn.guo@freescale.com \ --cc=shawn.guo@linaro.org \ --cc=tglx@linutronix.de \ /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: linkBe 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.