Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Rajendra Nayak [120620 23:33]: > On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote: > >* Rajendra Nayak [120606 22:33]: > >>Hi Tony, > >> > >>On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: > >>>* Rajendra Nayak [120601 05:13]: > The data is autogenerated using the OMAP autogeneration scripts (python > scripts). Thanks to Mike Turquette for the initial efforts in updating > the script which was later updated by me. > All data is added into a new cclock44xx_data.c file, a later patch will > get > rid of clock44xx_data.c file. > > Signed-off-by: Rajendra Nayak > --- > arch/arm/mach-omap2/cclock44xx_data.c | 2602 > +++ > arch/arm/mach-omap2/clock.h | 17 + > arch/arm/mach-omap2/clock_common_data.c | 14 + > arch/arm/mach-omap2/scrm44xx.h |2 + > 4 files changed, 2635 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c > >>> > >>>If you are adding new data anyways, why not add it to drivers/clock/omap > >>>to start with? > >> > >>Sorry, I missed out on responding to this one. > >>We won't be able to move just the new data but will need > >>all clkops handling around clksel/dpll etc also to be moved, > >>and I was thinking we might end up with 2 issues doing that. > > > >We should sort out those issues, sounds like we're missing few > >interfaces.. > > > >>-1- We have low level PRM/CM headers and apis used across multiple > >>frameworks for clocks/clockdomains/powerdomains and also some low > >>level PM code. This might get duplicated in drivers/clk and mach-omap2/ > > > >Well the PM code should be a loadable module using standard driver > >interfaces.. Maybe all it takes is adding few functions that both > >drivers/clk and mach-omap2 code can use without exposing all the registers? > >Then we may have a better idea what infrastructure pieces are missing. > > > >>-2- We still need to control clockdomains along with clocks atleast for > >>OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers > >>start using omap_device/runtime) and I am not sure how to do it with > >>the clockdomain framework residing in mach-omap2/ > > > >Maybe clockdomains could be also handled with some functions without > >exposing all the registers in the headers? > > Is moving some of the mach-omap2 headers into mach/include and > plat/include and using them in drivers/clk/omap an acceptable > first step? I see both the other architectures (imx and spear) > in drivers/clk already doing it. Yes if it helps to get things going. But it would be best to split the headers into common and private headers so only minimal amount of shared registers are defined in plat/include and mach/include. Otherwise those defines will get misused all over the place. Also note that names for the headers in plat/include and mach/include need to be omap specific for common zImage support. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
On Wednesday 20 June 2012 05:09 PM, Tony Lindgren wrote: * Rajendra Nayak [120606 22:33]: Hi Tony, On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: * Rajendra Nayak [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Sorry, I missed out on responding to this one. We won't be able to move just the new data but will need all clkops handling around clksel/dpll etc also to be moved, and I was thinking we might end up with 2 issues doing that. We should sort out those issues, sounds like we're missing few interfaces.. -1- We have low level PRM/CM headers and apis used across multiple frameworks for clocks/clockdomains/powerdomains and also some low level PM code. This might get duplicated in drivers/clk and mach-omap2/ Well the PM code should be a loadable module using standard driver interfaces.. Maybe all it takes is adding few functions that both drivers/clk and mach-omap2 code can use without exposing all the registers? Then we may have a better idea what infrastructure pieces are missing. -2- We still need to control clockdomains along with clocks atleast for OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers start using omap_device/runtime) and I am not sure how to do it with the clockdomain framework residing in mach-omap2/ Maybe clockdomains could be also handled with some functions without exposing all the registers in the headers? Is moving some of the mach-omap2 headers into mach/include and plat/include and using them in drivers/clk/omap an acceptable first step? I see both the other architectures (imx and spear) in drivers/clk already doing it. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Rajendra Nayak [120606 22:33]: > Hi Tony, > > On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: > >* Rajendra Nayak [120601 05:13]: > >>The data is autogenerated using the OMAP autogeneration scripts (python > >>scripts). Thanks to Mike Turquette for the initial efforts in updating > >>the script which was later updated by me. > >>All data is added into a new cclock44xx_data.c file, a later patch will get > >>rid of clock44xx_data.c file. > >> > >>Signed-off-by: Rajendra Nayak > >>--- > >> arch/arm/mach-omap2/cclock44xx_data.c | 2602 > >> +++ > >> arch/arm/mach-omap2/clock.h | 17 + > >> arch/arm/mach-omap2/clock_common_data.c | 14 + > >> arch/arm/mach-omap2/scrm44xx.h |2 + > >> 4 files changed, 2635 insertions(+), 0 deletions(-) > >> create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c > > > >If you are adding new data anyways, why not add it to drivers/clock/omap > >to start with? > > Sorry, I missed out on responding to this one. > We won't be able to move just the new data but will need > all clkops handling around clksel/dpll etc also to be moved, > and I was thinking we might end up with 2 issues doing that. We should sort out those issues, sounds like we're missing few interfaces.. > -1- We have low level PRM/CM headers and apis used across multiple > frameworks for clocks/clockdomains/powerdomains and also some low > level PM code. This might get duplicated in drivers/clk and mach-omap2/ Well the PM code should be a loadable module using standard driver interfaces.. Maybe all it takes is adding few functions that both drivers/clk and mach-omap2 code can use without exposing all the registers? Then we may have a better idea what infrastructure pieces are missing. > -2- We still need to control clockdomains along with clocks atleast for > OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers > start using omap_device/runtime) and I am not sure how to do it with > the clockdomain framework residing in mach-omap2/ Maybe clockdomains could be also handled with some functions without exposing all the registers in the headers? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
Hi Tony, On Tuesday 05 June 2012 12:12 PM, Tony Lindgren wrote: * Rajendra Nayak [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Sorry, I missed out on responding to this one. We won't be able to move just the new data but will need all clkops handling around clksel/dpll etc also to be moved, and I was thinking we might end up with 2 issues doing that. -1- We have low level PRM/CM headers and apis used across multiple frameworks for clocks/clockdomains/powerdomains and also some low level PM code. This might get duplicated in drivers/clk and mach-omap2/ -2- We still need to control clockdomains along with clocks atleast for OMAP2/3 (We should be able to get rid of it for OMAP4+ once all drivers start using omap_device/runtime) and I am not sure how to do it with the clockdomain framework residing in mach-omap2/ regards, Rajendra Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Tony Lindgren [120604 23:47]: > * Rajendra Nayak [120601 05:13]: > > The data is autogenerated using the OMAP autogeneration scripts (python > > scripts). Thanks to Mike Turquette for the initial efforts in updating > > the script which was later updated by me. > > All data is added into a new cclock44xx_data.c file, a later patch will get > > rid of clock44xx_data.c file. > > > > Signed-off-by: Rajendra Nayak > > --- > > arch/arm/mach-omap2/cclock44xx_data.c | 2602 > > +++ > > arch/arm/mach-omap2/clock.h | 17 + > > arch/arm/mach-omap2/clock_common_data.c | 14 + > > arch/arm/mach-omap2/scrm44xx.h |2 + > > 4 files changed, 2635 insertions(+), 0 deletions(-) > > create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c > > If you are adding new data anyways, why not add it to drivers/clock/omap > to start with? Sorry I mean drivers/clk/omap. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Rajendra Nayak [120601 05:13]: > The data is autogenerated using the OMAP autogeneration scripts (python > scripts). Thanks to Mike Turquette for the initial efforts in updating > the script which was later updated by me. > All data is added into a new cclock44xx_data.c file, a later patch will get > rid of clock44xx_data.c file. > > Signed-off-by: Rajendra Nayak > --- > arch/arm/mach-omap2/cclock44xx_data.c | 2602 > +++ > arch/arm/mach-omap2/clock.h | 17 + > arch/arm/mach-omap2/clock_common_data.c | 14 + > arch/arm/mach-omap2/scrm44xx.h |2 + > 4 files changed, 2635 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
Hi Jon,
+
+static const struct clksel_rate div_1_0_rates[] = {
+ { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel_rate div_1_1_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel_rate div_1_2_rates[] = {
+ { .div = 1, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel_rate div_1_3_rates[] = {
+ { .div = 1, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel_rate div_1_4_rates[] = {
+ { .div = 1, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
+
+static const struct clksel_rate div_1_5_rates[] = {
+ { .div = 1, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 0 },
+};
The above clksel_rate structures could be used by OMAP2/3 devices too
(assuming that the flags is set for OMAP2/3/4 devices). Any reason why
these cannot be placed in a global header? It could remove quite a bit
of repetitive code. I know these are auto-generated, but maybe we should
have the auto-generator spit out the clksel_rate structs to another file
(ie. a global header).
Well, I did not try doing any further optimizations and tried keeping
the same layout of data files so its easier to review, given the changes
already due to using common struct clk movement. We can certainly do
further optimizations/cleanups on top of this series.
I would really want to keep cleanups/optimizations separate (unless
they are cleanups/optimizations done as part of moving to common clk
itself) from common clk movement series. There are other optimizations
too like getting rid of some unwanted leaf clocks for omap4, moving
handling of clkdms for leaf clks into hwmod for OMAP2/3. But all those
are happening separately and can happen in the existing code without
having it being moved to common clk.
By the way, div_1_3/4/5_rates don't appear to be used in this file.
ok, thanks, will have a look and get rid of it if its really unused.
regards,
Rajendra
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
Hi Rajendra,
On 06/01/2012 07:07 AM, Rajendra Nayak wrote:
> The data is autogenerated using the OMAP autogeneration scripts (python
> scripts). Thanks to Mike Turquette for the initial efforts in updating
> the script which was later updated by me.
> All data is added into a new cclock44xx_data.c file, a later patch will get
> rid of clock44xx_data.c file.
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm/mach-omap2/cclock44xx_data.c | 2602
> +++
> arch/arm/mach-omap2/clock.h | 17 +
> arch/arm/mach-omap2/clock_common_data.c | 14 +
> arch/arm/mach-omap2/scrm44xx.h |2 +
> 4 files changed, 2635 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c
>
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
> b/arch/arm/mach-omap2/cclock44xx_data.c
> new file mode 100644
> index 000..fa421dc
> --- /dev/null
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -0,0 +1,2602 @@
> +/*
> + * OMAP4 Clock data
> + *
> + * Copyright (C) 2009-2012 Texas Instruments, Inc.
> + * Copyright (C) 2009-2010 Nokia Corporation
> + *
> + * Paul Walmsley (p...@pwsan.com)
> + * Rajendra Nayak (rna...@ti.com)
> + * Benoit Cousson (b-cous...@ti.com)
> + * Mike Turquette (mturque...@ti.com)
> + *
> + * This file is automatically generated from the OMAP hardware databases.
> + * We respectfully ask that any modifications to this file be coordinated
> + * with the public linux-omap@vger.kernel.org mailing list and the
> + * authors above to ensure that the autogeneration scripts are kept
> + * up-to-date with the file contents.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * XXX Some of the ES1 clocks have been removed/changed; once support
> + * is added for discriminating clocks by ES level, these should be added back
> + * in.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "iomap.h"
> +#include "clock.h"
> +#include "clock44xx.h"
> +#include "cm1_44xx.h"
> +#include "cm2_44xx.h"
> +#include "cm-regbits-44xx.h"
> +#include "prm44xx.h"
> +#include "prm-regbits-44xx.h"
> +#include "control.h"
> +#include "scrm44xx.h"
> +
> +/* OMAP4 modulemode control */
> +#define OMAP4430_MODULEMODE_HWCTRL_SHIFT 0
> +#define OMAP4430_MODULEMODE_SWCTRL_SHIFT 1
> +
> +/*LIST_HEAD(clocks);*/
> +
> +/* Root clocks */
> +
> +DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(pad_clks_src_ck, CLK_IS_ROOT, 1200, 0x0);
> +
> +DEFINE_CLK_GATE(pad_clks_ck, "pad_clks_src_ck", &pad_clks_src_ck, 0x0,
> + OMAP4430_CM_CLKSEL_ABE, OMAP4430_PAD_CLKS_GATE_SHIFT,
> + 0x0, NULL);
> +
> +DEFINE_CLK_FIXED_RATE(pad_slimbus_core_clks_ck, CLK_IS_ROOT, 1200, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(secure_32k_clk_src_ck, CLK_IS_ROOT, 32768, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(slimbus_src_clk, CLK_IS_ROOT, 1200, 0x0);
> +
> +DEFINE_CLK_GATE(slimbus_clk, "slimbus_src_clk", &slimbus_src_clk, 0x0,
> + OMAP4430_CM_CLKSEL_ABE, OMAP4430_SLIMBUS_CLK_GATE_SHIFT,
> + 0x0, NULL);
> +
> +DEFINE_CLK_FIXED_RATE(sys_32k_ck, CLK_IS_ROOT, 32768, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_1200_ck, CLK_IS_ROOT, 1200, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_1300_ck, CLK_IS_ROOT, 1300, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_1680_ck, CLK_IS_ROOT, 1680, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_1920_ck, CLK_IS_ROOT, 1920, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_2600_ck, CLK_IS_ROOT, 2600, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_2700_ck, CLK_IS_ROOT, 2700, 0x0);
> +
> +DEFINE_CLK_FIXED_RATE(virt_3840_ck, CLK_IS_ROOT, 3840, 0x0);
> +
> +static const struct clksel_rate div_1_0_rates[] = {
> + { .div = 1, .val = 0, .flags = RATE_IN_4430 },
> + { .div = 0 },
> +};
> +
> +static const struct clksel_rate div_1_1_rates[] = {
> + { .div = 1, .val = 1, .flags = RATE_IN_4430 },
> + { .div = 0 },
> +};
> +
> +static const struct clksel_rate div_1_2_rates[] = {
> + { .div = 1, .val = 2, .flags = RATE_IN_4430 },
> + { .div = 0 },
> +};
> +
> +static const struct clksel_rate div_1_3_rates[] = {
> + { .div = 1, .val = 3, .flags = RATE_IN_4430 },
> + { .div = 0 },
> +};
> +
> +static const struct clksel_rate div_1_4_rates[] = {
> + { .div = 1, .val = 4, .flags = RATE_IN_4430 },
> + { .div = 0 },
> +};
> +
> +static const struct clksel_rate div_1_5_rates[] = {
> + { .div = 1, .val = 5, .flags = RATE_IN_4430 },
> + { .div = 0 },
> +};
The above clksel_rate structures could be used by OMAP2/3 devices too
(assuming that the flags is set for OMAP2/3/4 devices). Any reason why
these cannot be placed in a global header? It could remove quite a bit
of repetitive c
