Re: [GIT PULL] clk: ti: clock driver code migration to drivers
Quoting Tony Lindgren (2015-07-14 03:40:06) * Tero Kristo t-kri...@ti.com [150714 03:34]: On 07/14/2015 12:54 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? Not after this series, was broken/obsolete already before. A couple of omap2/omap3 specific clock files still remain under mach-omap2, they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the painful core dvfs at some point again?), and parts of the omap2 core dpll handling code should probably be re-written; or at least verified that it actually works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with it I could probably try to get some sort of DVFS test case to work on the board farm OMAP2 board I have access to though, I can investigate this. People seem to still want the 1 GiHz support, but I think that only depends on the SmartReflex and some kind of replacement for voltagedomains. So if the core DVFS support is unused, I doubt it's very high on anybody's list right now. As long as the default is to have core running at the fast OPP then 1GHz should be fine. There is a voltage domain dependency from ARM-CORE when the ARM runs fast at 1GHZ: it requires core to run at the highest OPP as well. Regards, Mike And I take it's not obsolete or broken because of this series? :) No, this series does not touch the above mentioned pieces of code, so this definitely should not break anything. :) OK thanks for confirming that. 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 -- 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: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/16/2015 04:51 AM, Paul Walmsley wrote: On Tue, 14 Jul 2015, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 03:34]: On 07/14/2015 12:54 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? Not after this series, was broken/obsolete already before. A couple of omap2/omap3 specific clock files still remain under mach-omap2, they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the painful core dvfs at some point again?), and parts of the omap2 core dpll handling code should probably be re-written; or at least verified that it actually works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with it I could probably try to get some sort of DVFS test case to work on the board farm OMAP2 board I have access to though, I can investigate this. People seem to still want the 1 GiHz support, but I think that only depends on the SmartReflex and some kind of replacement for voltagedomains. So if the core DVFS support is unused, I doubt it's very high on anybody's list right now. At least several years ago, basic CORE DVFS support was working on OMAP3. The clock source changed rate, DRAM parameters were changed on the SDRC, etc. What was not implemented was pre-rate-change and post-rate-change notifiers in many of the device drivers, because the infrastructure didn't exist at the time in the clock code. Yes this is true, Nokia did an internal implementation for the pre/post notifier stuff which was never accepted upstream. The core dvfs code is no longer used in kernel for anything, it is just built in. The usefulness of the whole feature can be debated also, the use cases where it actually gives power savings is rather limited. I'll post a patch to remove the 'dead' core-dvfs code to the list, we can debate the issue there. -Tero -- 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: [GIT PULL] clk: ti: clock driver code migration to drivers
On Tue, 14 Jul 2015, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 03:34]: On 07/14/2015 12:54 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? Not after this series, was broken/obsolete already before. A couple of omap2/omap3 specific clock files still remain under mach-omap2, they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the painful core dvfs at some point again?), and parts of the omap2 core dpll handling code should probably be re-written; or at least verified that it actually works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with it I could probably try to get some sort of DVFS test case to work on the board farm OMAP2 board I have access to though, I can investigate this. People seem to still want the 1 GiHz support, but I think that only depends on the SmartReflex and some kind of replacement for voltagedomains. So if the core DVFS support is unused, I doubt it's very high on anybody's list right now. At least several years ago, basic CORE DVFS support was working on OMAP3. The clock source changed rate, DRAM parameters were changed on the SDRC, etc. What was not implemented was pre-rate-change and post-rate-change notifiers in many of the device drivers, because the infrastructure didn't exist at the time in the clock code. - Paul -- 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: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/14/2015 11:31 PM, Stephen Boyd wrote: On 07/14/2015 01:09 PM, Tero Kristo wrote: On 07/14/2015 10:29 PM, Stephen Boyd wrote: On 07/14/2015 01:54 AM, Tero Kristo wrote: The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) Why did this get rebased onto v4.2-rc2? I thought it was all ready to go based on v4.1-rc2? If possible leave it on v4.1-rc2 please. You mean 4.2-rc1 I guess...? Or do you really mean the old 4.1-rc2? Old 4.1-rc2 please Ok, posting a new one after this, this one can be ignored. -Tero -- 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: [GIT PULL] clk: ti: clock driver code migration to drivers
* Tero Kristo t-kri...@ti.com [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? And I take it's not obsolete or broken because of this series? :) Also, I just gave this branch a quick boot test and it seems to behave for me. 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
[GIT PULL] clk: ti: clock driver code migration to drivers
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
are available in the git repository at:
g...@github.com:t-kristo/linux-pm.git for-4.3/ti-clk-move
for you to fetch changes up to 792ee6c3ecf813a4e702bdaceee249c722ab89f5:
clk: ti: move low-level access and init code under clock driver
(2015-07-14 09:26:34 +0300)
Hi Mike, Stephen,
This pull request contains the TI clock driver set to move the clock
implementations under clock driver. Some small portions of the clock
driver code still remain under mach-omap2 after this, it should be
decided whether this code is now obsolete and should be deleted or
should someone try to fix it.
-Tero
Tero Kristo (27):
ARM: OMAP2+: clock: export driver API to setup/get clock features
clk: ti: move generic OMAP DPLL implementation under drivers/clk
clk: ti: move OMAP4+ DPLL implementation under drivers/clk
clk: ti: move interface clock implementation under drivers/clk
ARM: OMAP3: dpll3-m2: get rid of obsolete clksel access
ARM: OMAP2+: clk: remove obsolete clksel support code
ARM: OMAP2+: clock: remove clock_common_data.c file
ARM: OMAP36xx: remove clock36xx.c/.h files
clk: ti: autoidle: move generic autoidle handling code to clock
driver
clk: ti: move omap2_clk_enable_init_clocks under clock driver
ARM: OMAP2+: clock: remove support for legacy mpurate command
line param
ARM: OMAP2+: clock: add support for clkdm ops to the low level
clk ops
ARM: OMAP2+: clock: add support for specific CM ops to ti_clk_ll_ops
clk: ti: dpll: move omap3 DPLL functionality to clock driver
ARM: OMAP3: clock: remove clock3xxx.c file
ARM: OMAP2+: clock: remove clkdm_control static boolean from code
clk: ti: dflt: move support for default gate clock to clock driver
clk: ti: omap2430: move clock support code under clock driver
clk: ti: clkdm: move clkdm gate clock support code to clock driver
clk: ti: omap34xx: move omap34xx clock type support code to clock
driver
ARM: OMAP4: clock: remove clock44xx.h header
clk: ti: am3517: move remaining am3517 clock support code to
clock driver
clk: ti: move some public definitions to private header
ARM: OMAP2+: clock: remove dead definitions from the clock header
file
clk: ti: remove exported ll_ops struct, instead add an API for
registration
ARM: OMAP2+: clock: remove legacy omap2_clk_readl/writel APIs
clk: ti: move low-level access and init code under clock driver
arch/arm/mach-omap2/Makefile | 22 +-
arch/arm/mach-omap2/clkt34xx_dpll3m2.c |7 +-
arch/arm/mach-omap2/clkt_clksel.c | 466 --
arch/arm/mach-omap2/clkt_iclk.c| 68 --
arch/arm/mach-omap2/clock.c| 675
+---
arch/arm/mach-omap2/clock.h| 205 +-
arch/arm/mach-omap2/clock2430.c| 57 --
arch/arm/mach-omap2/clock2xxx.c| 57 --
arch/arm/mach-omap2/clock34xx.c| 138
arch/arm/mach-omap2/clock34xx.h| 18 -
arch/arm/mach-omap2/clock3517.c| 118
arch/arm/mach-omap2/clock3517.h| 14 -
arch/arm/mach-omap2/clock36xx.c| 69 --
arch/arm/mach-omap2/clock36xx.h| 13 -
arch/arm/mach-omap2/clock3xxx.c| 135
arch/arm/mach-omap2/clock44xx.h| 20 -
arch/arm/mach-omap2/clock_common_data.c| 115
arch/arm/mach-omap2/io.c |3 +-
drivers/clk/ti/Makefile| 17 +-
drivers/clk/ti/apll.c |2 +
drivers/clk/ti/autoidle.c | 121 +++-
drivers/clk/ti/clk-2xxx.c |2 +
drivers/clk/ti/clk-33xx.c |2 +
drivers/clk/ti/clk-3xxx.c | 244 +++
drivers/clk/ti/clk-43xx.c |2 +
drivers/clk/ti/clk-44xx.c |2 +
drivers/clk/ti/clk-54xx.c |2 +
drivers/clk/ti/clk-7xx.c |3 +-
drivers/clk/ti/clk-816x.c |2 +
drivers/clk/ti/clk.c | 145 -
drivers/clk/ti/clkt_dflt.c | 316 +
.../arm/mach-omap2 = drivers/clk/ti}/clkt_dpll.c | 27 +-
drivers/clk/ti/clkt_iclk.c | 101 +++
drivers/clk/ti/clock.h | 113
drivers/clk/ti/clockdomain.c | 78 +++
{arch/arm/mach-omap2 =
Re: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/14/2015 12:54 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? Not after this series, was broken/obsolete already before. A couple of omap2/omap3 specific clock files still remain under mach-omap2, they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the painful core dvfs at some point again?), and parts of the omap2 core dpll handling code should probably be re-written; or at least verified that it actually works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with it I could probably try to get some sort of DVFS test case to work on the board farm OMAP2 board I have access to though, I can investigate this. And I take it's not obsolete or broken because of this series? :) No, this series does not touch the above mentioned pieces of code, so this definitely should not break anything. :) -Tero Also, I just gave this branch a quick boot test and it seems to behave for me. 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: [GIT PULL] clk: ti: clock driver code migration to drivers
* Tero Kristo t-kri...@ti.com [150714 03:34]: On 07/14/2015 12:54 PM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [150714 01:56]: This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock driver code still remain under mach-omap2 after this, it should be decided whether this code is now obsolete and should be deleted or should someone try to fix it. Hmm care to clarify what is obsolete or broken after this series? Not after this series, was broken/obsolete already before. A couple of omap2/omap3 specific clock files still remain under mach-omap2, they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the painful core dvfs at some point again?), and parts of the omap2 core dpll handling code should probably be re-written; or at least verified that it actually works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with it I could probably try to get some sort of DVFS test case to work on the board farm OMAP2 board I have access to though, I can investigate this. People seem to still want the 1 GiHz support, but I think that only depends on the SmartReflex and some kind of replacement for voltagedomains. So if the core DVFS support is unused, I doubt it's very high on anybody's list right now. And I take it's not obsolete or broken because of this series? :) No, this series does not touch the above mentioned pieces of code, so this definitely should not break anything. :) OK thanks for confirming that. 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: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/14/2015 10:29 PM, Stephen Boyd wrote: On 07/14/2015 01:54 AM, Tero Kristo wrote: The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) Why did this get rebased onto v4.2-rc2? I thought it was all ready to go based on v4.1-rc2? If possible leave it on v4.1-rc2 please. You mean 4.2-rc1 I guess...? Or do you really mean the old 4.1-rc2? are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-4.3/ti-clk-move Also I can't fetch this. Please give a public URL and not the one you use for github. Oh sorry about that, git request-pull does this automatically. I'll update my script to use public URL. I fetched the for-4.2/ti-clk-move branch and did a test merge and fixed up omap3_noncore_dpll_determine_rate() and omap4_dpll_regm4xen_determine_rate() for the new determine rate signature and it looks like things are still compiling. So please redo the tag for that branch. Yea I can send a new pull-request tomorrow once my question is clarified. The code in the two branches is identical regarding the clock code changes, and both can be considered immutable and ready for pull if need be. -Tero 8- diff --cc include/linux/clk/ti.h index 448b4f87b9eb,f1838256fbaa.. --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h diff --git a/drivers/clk/ti/clock.h b/drivers/clk/ti/clock.h index d4d232fd89bc..d8aafd333058 100644 --- a/drivers/clk/ti/clock.h +++ b/drivers/clk/ti/clock.h @@ -250,12 +250,8 @@ int omap3_noncore_dpll_set_rate_and_parent(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate, u8 index); -long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, - unsigned long rate, - unsigned long min_rate, - unsigned long max_rate, - unsigned long *best_parent_rate, - struct clk_hw **best_parent_clk); +int omap3_noncore_dpll_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req); long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate, unsigned long *parent_rate); unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, @@ -273,12 +269,8 @@ unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw, long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw, unsigned long target_rate, unsigned long *parent_rate); -long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, -unsigned long rate, -unsigned long min_rate, -unsigned long max_rate, -unsigned long *best_parent_rate, -struct clk_hw **best_parent_clk); +int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req); extern struct ti_clk_ll_ops *ti_clk_ll_ops; -- 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: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/14/2015 01:54 AM, Tero Kristo wrote: The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) Why did this get rebased onto v4.2-rc2? I thought it was all ready to go based on v4.1-rc2? If possible leave it on v4.1-rc2 please. are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-4.3/ti-clk-move Also I can't fetch this. Please give a public URL and not the one you use for github. I fetched the for-4.2/ti-clk-move branch and did a test merge and fixed up omap3_noncore_dpll_determine_rate() and omap4_dpll_regm4xen_determine_rate() for the new determine rate signature and it looks like things are still compiling. So please redo the tag for that branch. 8- diff --cc include/linux/clk/ti.h index 448b4f87b9eb,f1838256fbaa.. --- a/include/linux/clk/ti.h +++ b/include/linux/clk/ti.h diff --git a/drivers/clk/ti/clock.h b/drivers/clk/ti/clock.h index d4d232fd89bc..d8aafd333058 100644 --- a/drivers/clk/ti/clock.h +++ b/drivers/clk/ti/clock.h @@ -250,12 +250,8 @@ int omap3_noncore_dpll_set_rate_and_parent(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate, u8 index); -long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, - unsigned long rate, - unsigned long min_rate, - unsigned long max_rate, - unsigned long *best_parent_rate, - struct clk_hw **best_parent_clk); +int omap3_noncore_dpll_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req); long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate, unsigned long *parent_rate); unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, @@ -273,12 +269,8 @@ unsigned long omap4_dpll_regm4xen_recalc(struct clk_hw *hw, long omap4_dpll_regm4xen_round_rate(struct clk_hw *hw, unsigned long target_rate, unsigned long *parent_rate); -long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, - unsigned long rate, - unsigned long min_rate, - unsigned long max_rate, - unsigned long *best_parent_rate, - struct clk_hw **best_parent_clk); +int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, + struct clk_rate_request *req); extern struct ti_clk_ll_ops *ti_clk_ll_ops; -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: [GIT PULL] clk: ti: clock driver code migration to drivers
On 07/14/2015 01:09 PM, Tero Kristo wrote: On 07/14/2015 10:29 PM, Stephen Boyd wrote: On 07/14/2015 01:54 AM, Tero Kristo wrote: The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590: Linux 4.2-rc2 (2015-07-12 15:10:30 -0700) Why did this get rebased onto v4.2-rc2? I thought it was all ready to go based on v4.1-rc2? If possible leave it on v4.1-rc2 please. You mean 4.2-rc1 I guess...? Or do you really mean the old 4.1-rc2? Old 4.1-rc2 please -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
