| Message ID | 1348683037-9705-10-git-send-email-m-karicheri2@ti.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
Murali, On 9/26/2012 11:40 PM, Murali Karicheri wrote: > The clock tree for dm644x is defined using the new structure davinci_clk. > The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux > drivers in addition to the davinci specific clk drivers, clk-davinci-pll > and clk-davinci-psc. Macros are defined to define the various clocks in > the SoC. > > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> You have chosen to keep all clock related data in platform files while using the common clock framework to provide just the infrastructure. If you look at how mxs and spear have been migrated, they have migrated the soc specific clock data to drivers/clk as well. See "drivers/clk/spear/spear3xx_clock.c" or "drivers/clk/mxs/clk-imx23.c". I feel the latter way is better and I also think it will simplify some of the look-up infrastructure you had to build. This will also help some real code reduction from arch/arm/mach-davinci/. Thanks, Sekhar
>> -----Original Message----- >> From: Nori, Sekhar >> Sent: Thursday, October 11, 2012 8:25 AM >> To: Karicheri, Muralidharan >> Cc: mturquette@linaro.org; arnd@arndb.de; akpm@linux-foundation.org; >> shawn.guo@linaro.org; rob.herring@calxeda.com; linus.walleij@linaro.org; >> viresh.linux@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin; >> linux@arm.linux.org.uk; davinci-linux-open-source@linux.davincidsp.com; linux-arm- >> kernel@lists.infradead.org; linux-keystone@list.ti.com - Linux developers for Keystone >> family of devices (May contain non-TIers); linux-c6x-dev@linux-c6x.org; Chemparathy, >> Cyril >> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use >> common clk drivers >> >> Murali, >> >> On 9/26/2012 11:40 PM, Murali Karicheri wrote: >> > The clock tree for dm644x is defined using the new structure davinci_clk. >> > The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux >> > drivers in addition to the davinci specific clk drivers, >> > clk-davinci-pll and clk-davinci-psc. Macros are defined to define the >> > various clocks in the SoC. >> > >> > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> >> >> You have chosen to keep all clock related data in platform files while using the common >> clock framework to provide just the infrastructure. If you look at how mxs and spear >> have been migrated, they have migrated the soc specific clock data to drivers/clk as well. >> See "drivers/clk/spear/spear3xx_clock.c" or "drivers/clk/mxs/clk-imx23.c I have to disagree on this one. I had investigated these code already and came up with a way that we can re-use code across all of the davinci platforms as well as other architectures that re-uses the clk hardware IPs. spear3xx_clock.c has initialization code for each of the platforms and so is the case with imx23.c. By using platform_data approach, we are able to define clks for each of the SoC and then use davinci_common_clk_init() to do initialize the clk drivers based on platform data. Later once we migrate to device tree, davinci_common_clk_init() will go way and also the clk structures defined in the SoC file. I have prototyped this on one of the device that I am working on. davinci_common_clk_init() will be replaced with a of_davinci_clk_init() that will use device tree to get all of the platform data for the clk providers and do the initialization based on that. See highbank_clocks_init() in clk-highbank.c. I have used this model for device tree based clk initialization. So it make sense to keep the design the way it is. Otherwise we will end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and these code will get thrown away once we migrate to device tree. >>". I feel the >> latter way is better and I also think it will simplify some of the look-up infrastructure you >> had to build. This will also help some real code reduction from arch/arm/mach-davinci/. >> The look-up infrastructure is pretty much re-use of the existing code base in SoC specific file. About code reduction, I can't say I agree, as we need to add platform_specific clock initialization code if we follow spear3xx_clock.c model and end up probably adding more code. SoC specific file (for example dm644x.c) has only data structures and all of SoC will re-use davinci_common_clk_init() to do the initialization. So I am not sure how you conclude we will have code reduction? - Murali >> Thanks, >> Sekhar
Hi Murali, On 10/11/2012 8:28 PM, Karicheri, Muralidharan wrote: >>> -----Original Message----- >>> From: Nori, Sekhar >>> Sent: Thursday, October 11, 2012 8:25 AM >>> To: Karicheri, Muralidharan >>> Cc: mturquette@linaro.org; arnd@arndb.de; akpm@linux-foundation.org; >>> shawn.guo@linaro.org; rob.herring@calxeda.com; linus.walleij@linaro.org; >>> viresh.linux@gmail.com; linux-kernel@vger.kernel.org; Hilman, Kevin; >>> linux@arm.linux.org.uk; davinci-linux-open-source@linux.davincidsp.com; linux-arm- >>> kernel@lists.infradead.org; linux-keystone@list.ti.com - Linux developers for Keystone >>> family of devices (May contain non-TIers); linux-c6x-dev@linux-c6x.org; Chemparathy, >>> Cyril >>> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use >>> common clk drivers >>> >>> Murali, >>> >>> On 9/26/2012 11:40 PM, Murali Karicheri wrote: >>>> The clock tree for dm644x is defined using the new structure davinci_clk. >>>> The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux >>>> drivers in addition to the davinci specific clk drivers, >>>> clk-davinci-pll and clk-davinci-psc. Macros are defined to define the >>>> various clocks in the SoC. >>>> >>>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> >>> >>> You have chosen to keep all clock related data in platform files while using the common >>> clock framework to provide just the infrastructure. If you look at how mxs and spear >>> have been migrated, they have migrated the soc specific clock data to drivers/clk as well. >>> See "drivers/clk/spear/spear3xx_clock.c" or "drivers/clk/mxs/clk-imx23.c > > I have to disagree on this one. I had investigated these code already and came > up with a way that we can re-use code across all of the davinci platforms as > well as other architectures that re-uses the clk hardware IPs. Which code you are talking about here? Even if you introduce clk-dm644x.c, clk-keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce in patches 1-3. I cant see how that will be prevented. > spear3xx_clock.c has initialization code for each of the platforms > and so is the case with imx23.c. By each of the platforms, you mean they all cater to a family of devices? This depends on how close together the family of devices are. Otherwise, there would be a file per soc. DM644x also represents a family for that matter. > By using platform_data approach, we are able to define clks for each of the SoC and then use davinci_common_clk_init() to do initialize the clk drivers based on platform data. You need to define and register the clocks present on each SoC either which way. I don't see why just the platform_data approach allows this. And looking closely, you have defined platform data, but don't actually have a platform device, making things more confusing. > Later once we migrate to device tree, davinci_common_clk_init() will go way and also the clk structures defined in the SoC file. I have prototyped this on one of the device that I am working on. davinci_common_clk_init() will be replaced with a of_davinci_clk_init() that will use device tree to get all of the platform data for the clk providers and do the initialization based on that. See highbank_clocks_init() in clk-highbank.c. I have used this model for device > tree based clk initialization. I don't think we should wait till DT migration to get rid of clock data from platform code. For many of the older DaVinci platforms, DT migration is a big if and when. This approach you gave above might work for newer DT-only platforms, but even if there is one board that is not migrated to DT, the entire clock data will have to stay. I have very less hope this will happen for DaVinci (at least in the near term). So, I would rather take the opportunity of common clock tree migration to move clock data out of mach-davinci. Also, just moving soc-specific clk data to drivers/clk/davinci/* does not impede a future DT conversion, no? > So it make sense to keep the design the way it is. Otherwise we will end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and these code will get thrown away once we migrate to > device tree. I still don't see why davinci/keystone cannot follow the same approach taken by multiple other socs - spear, mxs and ux500. I am unconvinced that we have a significantly different case. >>> ". I feel the >>> latter way is better and I also think it will simplify some of the look-up infrastructure you >>> had to build. This will also help some real code reduction from arch/arm/mach-davinci/. >>> > > The look-up infrastructure is pretty much re-use of the existing code base in SoC specific file. Yes, but that's no reason to keep maintaining it. > About code reduction, I can't say I agree, as we need to add platform_specific clock initialization code if we follow spear3xx_clock.c model and end up probably adding more code. > SoC specific file (for example dm644x.c) has only data structures and all of SoC will re-use davinci_common_clk_init() to do the initialization. So I am not sure how you conclude we will have code reduction? Is about code reduction from arch/arm/. That's what ARM community is working towards. Thanks, Sekhar PS: When replying, can you please hit an enter after every 70 or so characters. Otherwise quoting from your mails is becoming very difficult. I tried manually adjusting it but finally gave up.
--Cut---- >> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use >> common clk drivers >> >> >>> You have chosen to keep all clock related data in platform files >> >>> while using the common clock framework to provide just the >> >>> infrastructure. If you look at how mxs and spear have been migrated, they have >> migrated the soc specific clock data to drivers/clk as well. >> >>> See "drivers/clk/spear/spear3xx_clock.c" or >> >>> "drivers/clk/mxs/clk-imx23.c >> > >> > I have to disagree on this one. I had investigated these code already >> > and came up with a way that we can re-use code across all of the >> > davinci platforms as well as other architectures that re-uses the clk hardware IPs. >> >> Which code you are talking about here? Even if you introduce clk-dm644x.c, clk- >> keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce in patches 1- >> 3. I cant see how that will be prevented. I was talking about re-use of davinci_common_clk_init in drivers/clk/davinci/davinci-clock.c. This is meant to be re-used across all of the DaVinci devices. >> >> > spear3xx_clock.c has initialization code for each of the platforms and >> > so is the case with imx23.c. >> >> By each of the platforms, you mean they all cater to a family of devices? This depends on >> how close together the family of devices are. >> Otherwise, there would be a file per soc. DM644x also represents a family for that matter. >> >> > By using platform_data approach, we are able to define clks for each of the SoC and >> then use davinci_common_clk_init() to do initialize the clk drivers based on platform >> data. >> >> You need to define and register the clocks present on each SoC either which way. I don't >> see why just the platform_data approach allows this. >> And looking closely, you have defined platform data, but don't actually have a platform >> device, making things more confusing. >> Ok. There are multiple ways to implement this software. We had discussed this internally and picked the platform_data approach. The clk drivers are written not following the platform driver model. But I don't see why we can't use platform data to configure this drivers. Down below, you have made two interesting points, one is ARM code reduction. This patch already does this by moving the API that initializes the clk drivers (davinci_common_clk_init()) out of ARM to drivers/clk/davinci. So this + removal of existing clk driver under arm/mach-davinci/clock.[ch], we have achieved this goal. The second point is the moving of SoC specific clk data out of SoC code to drive. Are you 100% sure this is the right thing to do for these drivers. If so, I can start working on this change right away. As I am working on this as a background activity, I want to be double or triple sure before doing the rework of these patches :). So please confirm. >> > Later once we migrate to device tree, davinci_common_clk_init() will >> > go way and also the clk structures defined in the SoC file. I have prototyped this on >> one of the device that I am working on. davinci_common_clk_init() will be replaced with a >> of_davinci_clk_init() that will use device tree to get all of the platform data for the clk >> providers and do the initialization based on that. See highbank_clocks_init() in clk- >> highbank.c. I have used this model for device tree based clk initialization. >> >> I don't think we should wait till DT migration to get rid of clock data from platform code. >> For many of the older DaVinci platforms, DT migration is a big if and when. This approach >> you gave above might work for newer DT-only platforms, but even if there is one board >> that is not migrated to DT, the entire clock data will have to stay. I have very less hope >> this will happen for DaVinci (at least in the near term). So, I would rather take the >> opportunity of common clock tree migration to move clock data out of mach-davinci. >> >> Also, just moving soc-specific clk data to drivers/clk/davinci/* does not impede a future >> DT conversion, no? >> >> > So it make sense to keep the design the way it is. Otherwise we will >> > end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and >> these code will get thrown away once we migrate to device tree. >> >> I still don't see why davinci/keystone cannot follow the same approach taken by multiple >> other socs - spear, mxs and ux500. I am unconvinced that we have a significantly >> different case. >> >> >>> ". I feel the >> >>> latter way is better and I also think it will simplify some of the >> >>> look-up infrastructure you had to build. This will also help some real code reduction >> from arch/arm/mach-davinci/. >> >>> >> > >> > The look-up infrastructure is pretty much re-use of the existing code base in SoC >> specific file. >> >> Yes, but that's no reason to keep maintaining it. >> >> > About code reduction, I can't say I agree, as we need to add platform_specific clock >> initialization code if we follow spear3xx_clock.c model and end up probably adding more >> code. >> > SoC specific file (for example dm644x.c) has only data structures and all of SoC will re- >> use davinci_common_clk_init() to do the initialization. So I am not sure how you conclude >> we will have code reduction? >> >> Is about code reduction from arch/arm/. That's what ARM community is working towards. >> >> Thanks, >> Sekhar >> >> PS: When replying, can you please hit an enter after every 70 or so characters. >> Otherwise quoting from your mails is becoming very difficult. I tried manually adjusting it >> but finally gave up.
Hi Murali, On 10/15/2012 9:21 PM, Karicheri, Muralidharan wrote: > --Cut---- > >>> Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use >>> common clk drivers >>> >>>>>> You have chosen to keep all clock related data in platform files >>>>>> while using the common clock framework to provide just the >>>>>> infrastructure. If you look at how mxs and spear have been migrated, they have >>> migrated the soc specific clock data to drivers/clk as well. >>>>>> See "drivers/clk/spear/spear3xx_clock.c" or >>>>>> "drivers/clk/mxs/clk-imx23.c >>>> >>>> I have to disagree on this one. I had investigated these code already >>>> and came up with a way that we can re-use code across all of the >>>> davinci platforms as well as other architectures that re-uses the clk hardware IPs. >>> >>> Which code you are talking about here? Even if you introduce clk-dm644x.c, clk- >>> keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce in patches 1- >>> 3. I cant see how that will be prevented. > > I was talking about re-use of davinci_common_clk_init in drivers/clk/davinci/davinci-clock.c. > This is meant to be re-used across all of the DaVinci devices. > >>> >>>> spear3xx_clock.c has initialization code for each of the platforms and >>>> so is the case with imx23.c. >>> >>> By each of the platforms, you mean they all cater to a family of devices? This depends on >>> how close together the family of devices are. >>> Otherwise, there would be a file per soc. DM644x also represents a family for that matter. >>> >>>> By using platform_data approach, we are able to define clks for each of the SoC and >>> then use davinci_common_clk_init() to do initialize the clk drivers based on platform >>> data. >>> >>> You need to define and register the clocks present on each SoC either which way. I don't >>> see why just the platform_data approach allows this. >>> And looking closely, you have defined platform data, but don't actually have a platform >>> device, making things more confusing. >>> > > Ok. There are multiple ways to implement this software. We had discussed this > internally and picked the platform_data approach. The clk drivers are written not > following the platform driver model. But I don't see why we can't use platform data > to configure this drivers. Down below, you have made two interesting points, one is > ARM code reduction. This patch already does this by moving the API that initializes > the clk drivers (davinci_common_clk_init()) out of ARM to drivers/clk/davinci. So > this + removal of existing clk driver under arm/mach-davinci/clock.[ch], we have > achieved this goal. The second point is the moving of SoC specific clk data out of SoC > code to drive. Are you 100% sure this is the right thing to do for these drivers. If so, > I can start working on this change right away. As I am working on this as a background > activity, I want to be double or triple sure before doing the rework of these patches :). > So please confirm. Yes, this is the right way to go. And I don't see it as something breaking new ground since there are already multiple SoCs in mainline which are following this same approach. May be to start with just convert one SoC and send for review. Thanks for taking this up and helping clean-up mach-davinci. Regards, Sekhar
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 0755d46..7a1796e 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -12,6 +12,14 @@ #include <linux/clk.h> #include <linux/serial_8250.h> #include <linux/platform_device.h> +#ifdef CONFIG_COMMON_CLK +#include <linux/clkdev.h> +#include <linux/clk-provider.h> +#include <linux/platform_data/clk-davinci-pll.h> +#include <linux/platform_data/clk-davinci-psc.h> +#include <linux/platform_data/davinci-clock.h> +#include <mach/pll.h> +#endif #include <asm/mach/map.h> @@ -26,9 +34,16 @@ #include <mach/gpio-davinci.h> #include "davinci.h" -#include "clock.h" #include "mux.h" #include "asp.h" +#ifndef CONFIG_COMMON_CLK +#include "clock.h" +#else +#define PLLM 0x110 +#define PREDIV 0x114 +#define POSTDIV 0x128 +#define PLLM_PLLM_MASK 0xff +#endif /* * Device specific clocks @@ -42,6 +57,7 @@ #define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000 #define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000 +#ifndef CONFIG_COMMON_CLK static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, @@ -324,6 +340,288 @@ static struct clk_lookup dm644x_clks[] = { CLK("watchdog", NULL, &timer2_clk), CLK(NULL, NULL, NULL), }; +#else +static struct clk_davinci_pll_data pll1_data = { + .phy_pllm = DAVINCI_PLL1_BASE + PLLM, + .phy_prediv = DAVINCI_PLL1_BASE + PREDIV, + .phy_postdiv = DAVINCI_PLL1_BASE + POSTDIV, + .pllm_mask = PLLM_PLLM_MASK, + .prediv_mask = PLLDIV_RATIO_MASK, + .postdiv_mask = PLLDIV_RATIO_MASK, + .num = 1, +}; + +static struct clk_fixed_rate_data clkin_data = { + .rate = DM644X_REF_FREQ, + .flags = CLK_IS_ROOT, +}; + +static struct davinci_clk ref_clk_clkin = { + .name = "clkin", + .type = DAVINCI_FIXED_RATE_CLK, + .clk_data = { + .data = &clkin_data, + }, +}; + +static struct clk_fixed_rate_data oscin_data = { + .rate = DM644X_REF_FREQ, + .flags = CLK_IS_ROOT, +}; + +static struct davinci_clk ref_clk_oscin = { + .name = "oscin", + .type = DAVINCI_FIXED_RATE_CLK, + .clk_data = { + .data = &oscin_data, + }, +}; + +static const char *ref_clk_mux_parents[] = {"clkin", "oscin"}; + +static struct clk_mux_data ref_clk_mux_data = { + .shift = PLLCTL_CLKMODE_SHIFT, + .width = PLLCTL_CLKMODE_WIDTH, + .num_parents = ARRAY_SIZE(ref_clk_mux_parents), + .parents = ref_clk_mux_parents, + .phys_base = DAVINCI_PLL1_BASE + PLLCTL, +}; + +static struct davinci_clk ref_clk_mux = { + .name = "ref_clk_mux", + .parent = &ref_clk_clkin, + .type = DAVINCI_MUX_CLK, + .clk_data = { + .data = &ref_clk_mux_data, + } +}; + +static struct davinci_clk pll1_clk = { + .name = "pll1", + .parent = &ref_clk_mux, + .type = DAVINCI_MAIN_PLL_CLK, + .clk_data = { + .data = &pll1_data, + }, +}; + +static const char *pll1_plldiv_clk_mux_parents[] = { + "ref_clk_mux", "pll1"}; + +static struct clk_mux_data pll1_plldiv_clk_mux_data = { + .shift = PLLCTL_PLLEN_SHIFT, + .width = PLLCTL_PLLEN_WIDTH, + .num_parents = ARRAY_SIZE(pll1_plldiv_clk_mux_parents), + .parents = pll1_plldiv_clk_mux_parents, + .phys_base = DAVINCI_PLL1_BASE + PLLCTL, +}; + +static struct davinci_clk pll1_plldiv_clk_mux = { + .name = "pll1_plldiv_clk_mux", + .parent = &pll1_clk, + .type = DAVINCI_MUX_CLK, + .clk_data = { + .data = &pll1_plldiv_clk_mux_data, + }, +}; + +#define define_pll1_div_clk(__pll, __div, __name) \ + static struct clk_divider_data pll1_div_data##__div = { \ + .div_reg = DAVINCI_PLL1_BASE + PLLDIV##__div, \ + .width = 5, \ + }; \ + \ + static struct davinci_clk __name = { \ + .name = #__name, \ + .parent = &__pll, \ + .type = DAVINCI_PRG_DIV_CLK, \ + .clk_data = { \ + .data = &pll1_div_data##__div, \ + }, \ + }; + +define_pll1_div_clk(pll1_plldiv_clk_mux, 1, pll1_sysclk1); +define_pll1_div_clk(pll1_plldiv_clk_mux, 2, pll1_sysclk2); +define_pll1_div_clk(pll1_plldiv_clk_mux, 3, pll1_sysclk3); +define_pll1_div_clk(pll1_plldiv_clk_mux, 4, pll1_sysclk4); +define_pll1_div_clk(pll1_plldiv_clk_mux, 5, pll1_sysclk5); + +static struct clk_divider_data pll1_sysclkbp_data = { + .div_reg = BPDIV, +}; + +static struct davinci_clk pll1_sysclkbp = { + .name = "pll1_sysclkbp", + .parent = &ref_clk_mux, + .type = DAVINCI_PRG_DIV_CLK, + .clk_data = { + .data = &pll1_sysclkbp_data, + }, +}; + +static struct clk_davinci_pll_data pll2_data = { + .phy_pllm = DAVINCI_PLL2_BASE + PLLM, + .phy_prediv = DAVINCI_PLL2_BASE + PREDIV, + .phy_postdiv = DAVINCI_PLL2_BASE + POSTDIV, + .pllm_mask = PLLM_PLLM_MASK, + .prediv_mask = PLLDIV_RATIO_MASK, + .postdiv_mask = PLLDIV_RATIO_MASK, + .num = 2, +}; + +static struct davinci_clk pll2_clk = { + .name = "pll2", + .type = DAVINCI_MAIN_PLL_CLK, + .parent = &ref_clk_mux, + .clk_data = { + .data = &pll2_data, + }, +}; + +#define define_pll2_div_clk(__pll, __div, __name) \ + static struct clk_divider_data pll2_div_data##__div = { \ + .div_reg = DAVINCI_PLL2_BASE + PLLDIV##__div, \ + .width = 5, \ + }; \ + \ + static struct davinci_clk __name = { \ + .name = #__name, \ + .parent = &__pll, \ + .type = DAVINCI_PRG_DIV_CLK, \ + .clk_data = { \ + .data = &pll2_div_data##__div, \ + }, \ + }; + +static const char *pll2_plldiv_clk_mux_parents[] = { + "ref_clk_mux", "pll2"}; + +static struct clk_mux_data pll2_plldiv_clk_mux_data = { + .shift = PLLCTL_PLLEN_SHIFT, + .width = PLLCTL_PLLEN_WIDTH, + .num_parents = ARRAY_SIZE(pll2_plldiv_clk_mux_parents), + .parents = pll2_plldiv_clk_mux_parents, + .phys_base = DAVINCI_PLL2_BASE + PLLCTL, +}; + +static struct davinci_clk pll2_plldiv_clk_mux = { + .name = "pll2_plldiv_clk_mux", + .parent = &pll2_clk, + .type = DAVINCI_MUX_CLK, + .clk_data = { + .data = &pll2_plldiv_clk_mux_data, + }, +}; + +define_pll2_div_clk(pll2_plldiv_clk_mux, 1, pll2_sysclk1); +define_pll2_div_clk(pll2_plldiv_clk_mux, 2, pll2_sysclk2); + +static struct clk_divider_data pll2_sysclkbp_data = { + .div_reg = DAVINCI_PLL2_BASE + BPDIV, + .width = 5, +}; + +static struct davinci_clk pll2_sysclkbp = { + .name = "pll2_sysclkbp", + .parent = &ref_clk_mux, + .type = DAVINCI_PRG_DIV_CLK, + .clk_data = { + .data = &pll2_sysclkbp_data, + }, +}; + +#define __lpsc_clk(cname, _parent, mod, flgs, _flgs, dom) \ + static struct clk_davinci_psc_data clk_psc_data##cname = { \ + .domain = DAVINCI_GPSC_##dom, \ + .lpsc = DAVINCI_LPSC_##mod, \ + .flags = flgs, \ + }; \ + \ + static struct davinci_clk clk_##cname = { \ + .name = #cname, \ + .parent = &_parent, \ + .flags = _flgs, \ + .type = DAVINCI_PSC_CLK, \ + .clk_data = { \ + .data = &clk_psc_data##cname \ + }, \ + }; + +#define lpsc_clk_enabled(cname, parent, mod) \ + __lpsc_clk(cname, parent, mod, 0, ALWAYS_ENABLED, ARMDOMAIN) + +#define lpsc_clk(cname, flgs, parent, mod, dom) \ + __lpsc_clk(cname, parent, mod, flgs, 0, dom) + +lpsc_clk_enabled(arm, pll1_sysclk2, ARM); +lpsc_clk(dsp, CLK_IGNORE_UNUSED, pll1_sysclk1, GEM, DSPDOMAIN); +lpsc_clk(vicp, CLK_IGNORE_UNUSED, pll1_sysclk2, IMCOP, DSPDOMAIN); +lpsc_clk(vpss_master, 0, pll1_sysclk3, VPSSMSTR, ARMDOMAIN); +lpsc_clk(vpss_slave, 0, pll1_sysclk3, VPSSSLV, ARMDOMAIN); +lpsc_clk(uart0, 0, ref_clk_mux, UART0, ARMDOMAIN); +lpsc_clk(uart1, 0, ref_clk_mux, UART1, ARMDOMAIN); +lpsc_clk(uart2, 0, ref_clk_mux, UART2, ARMDOMAIN); +lpsc_clk(emac, 0, pll1_sysclk5, EMAC_WRAPPER, ARMDOMAIN); +lpsc_clk(i2c, 0, ref_clk_mux, I2C, ARMDOMAIN); +lpsc_clk(ide, 0, pll1_sysclk5, ATA, ARMDOMAIN); +lpsc_clk(asp0, 0, pll1_sysclk5, McBSP, ARMDOMAIN); +lpsc_clk(mmcsd, 0, pll1_sysclk5, MMC_SD, ARMDOMAIN); +lpsc_clk(spi, 0, pll1_sysclk5, SPI, ARMDOMAIN); +lpsc_clk(gpio, 0, pll1_sysclk5, GPIO, ARMDOMAIN); +lpsc_clk(usb, 0, pll1_sysclk5, USB, ARMDOMAIN); +lpsc_clk(vlynq, 0, pll1_sysclk5, VLYNQ, ARMDOMAIN); +lpsc_clk(aemif, 0, pll1_sysclk5, AEMIF, ARMDOMAIN); +lpsc_clk(pwm0, 0, ref_clk_mux, PWM0, ARMDOMAIN); +lpsc_clk(pwm1, 0, ref_clk_mux, PWM1, ARMDOMAIN); +lpsc_clk(pwm2, 0, ref_clk_mux, PWM2, ARMDOMAIN); +lpsc_clk(timer0, 0, ref_clk_mux, TIMER0, ARMDOMAIN); +lpsc_clk(timer1, 0, ref_clk_mux, TIMER1, ARMDOMAIN); +lpsc_clk(timer2, CLK_IGNORE_UNUSED, ref_clk_mux, TIMER2, ARMDOMAIN); + +static struct davinci_clk_lookup dm644x_clks[] = { + CLK(NULL, "clkin", &ref_clk_clkin), + CLK(NULL, "oscin", &ref_clk_oscin), + CLK(NULL, "ref_clk_mux", &ref_clk_mux), + CLK(NULL, "pll1", &pll1_clk), + CLK(NULL, "pll1_plldiv_clk_mux", &pll1_plldiv_clk_mux), + CLK(NULL, "pll1_sysclk1", &pll1_sysclk1), + CLK(NULL, "pll1_sysclk2", &pll1_sysclk2), + CLK(NULL, "pll1_sysclk3", &pll1_sysclk3), + CLK(NULL, "pll1_sysclk4", &pll1_sysclk4), + CLK(NULL, "pll1_sysclk5", &pll1_sysclk5), + CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp), + CLK(NULL, "pll2", &pll2_clk), + CLK(NULL, "pll2_plldiv_clk_mux", &pll2_plldiv_clk_mux), + CLK(NULL, "pll2_sysclk1", &pll2_sysclk1), + CLK(NULL, "pll2_sysclk2", &pll2_sysclk2), + CLK(NULL, "pll2_sysclkbp", &pll2_sysclkbp), + CLK(NULL, "dsp", &clk_dsp), + CLK(NULL, "arm", &clk_arm), + CLK(NULL, "vicp", &clk_vicp), + CLK(NULL, "vpss_master", &clk_vpss_master), + CLK(NULL, "vpss_slave", &clk_vpss_slave), + CLK(NULL, "uart0", &clk_uart0), + CLK(NULL, "uart1", &clk_uart1), + CLK(NULL, "uart2", &clk_uart2), + CLK("davinci_emac.1", NULL, &clk_emac), + CLK("i2c_davinci.1", NULL, &clk_i2c), + CLK("palm_bk3710", NULL, &clk_ide), + CLK("davinci-mcbsp", NULL, &clk_asp0), + CLK("davinci_mmc.0", NULL, &clk_mmcsd), + CLK(NULL, "spi", &clk_spi), + CLK(NULL, "gpio", &clk_gpio), + CLK(NULL, "usb", &clk_usb), + CLK(NULL, "vlynq", &clk_vlynq), + CLK(NULL, "aemif", &clk_aemif), + CLK(NULL, "pwm0", &clk_pwm0), + CLK(NULL, "pwm1", &clk_pwm1), + CLK(NULL, "pwm2", &clk_pwm2), + CLK(NULL, "timer0", &clk_timer0), + CLK(NULL, "timer1", &clk_timer1), + CLK("watchdog", NULL, &clk_timer2), + CLK(NULL, NULL, NULL), +}; +#endif static struct emac_platform_data dm644x_emac_pdata = { .ctrl_reg_offset = DM644X_EMAC_CNTRL_OFFSET, @@ -873,6 +1171,32 @@ static struct platform_device dm644x_serial_device = { }, }; +#ifdef CONFIG_COMMON_CLK +struct clk_lookup vpss_master_lookups[] = { + { .dev_id = "dm644x_ccdc", .con_id = "master", }, +}; + +struct clk_lookup vpss_slave_lookups[] = { + { .dev_id = "dm644x_ccdc", .con_id = "slave", }, +}; + +static struct davinci_dev_lookup dev_clk_lookups[] = { + { + .con_id = "vpss_master", + .num_devs = ARRAY_SIZE(vpss_master_lookups), + .lookups = vpss_master_lookups, + }, + { + .con_id = "vpss_slave", + .num_devs = ARRAY_SIZE(vpss_slave_lookups), + .lookups = vpss_slave_lookups, + }, + { + .con_id = NULL, + }, +}; +#endif + static struct davinci_soc_info davinci_soc_info_dm644x = { .io_desc = dm644x_io_desc, .io_desc_num = ARRAY_SIZE(dm644x_io_desc), @@ -880,6 +1204,9 @@ static struct davinci_soc_info davinci_soc_info_dm644x = { .ids = dm644x_ids, .ids_num = ARRAY_SIZE(dm644x_ids), .cpu_clks = dm644x_clks, +#ifdef CONFIG_COMMON_CLK + .dev_clk_lookups = dev_clk_lookups, +#endif .psc_bases = dm644x_psc_bases, .psc_bases_num = ARRAY_SIZE(dm644x_psc_bases), .pinmux_base = DAVINCI_SYSTEM_MODULE_BASE, @@ -923,11 +1250,13 @@ int __init dm644x_init_video(struct vpfe_config *vpfe_cfg, dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; platform_device_register(&dm644x_ccdc_dev); platform_device_register(&dm644x_vpfe_dev); +#ifndef CONFIG_COMMON_CLK /* Add ccdc clock aliases */ clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); +#endif } if (vpbe_cfg) {
The clock tree for dm644x is defined using the new structure davinci_clk. The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux drivers in addition to the davinci specific clk drivers, clk-davinci-pll and clk-davinci-psc. Macros are defined to define the various clocks in the SoC. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>