Skip to contentSkip to conversation

clk: ti: clock driver code migration to drivers

GIT PULL Tero Kristo 5 participants 11 messages Jul 14, 2015 – Jul 24, 2015

Subsystems (2)
Common clk TI clock driver
lore
Share & tools
lore

Tero Kristo

author
#0 lore raw

The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:

Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)

are available in the git repository at:

[email protected]: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 => drivers/clk/ti}/dpll3xxx.c |  157 ++---
 {arch/arm/mach-omap2 => drivers/clk/ti}/dpll44xx.c |   23 +-
 drivers/clk/ti/fixed-factor.c                      |    2 +
 include/linux/clk/ti.h                             |  157 ++---
 39 files changed, 1328 insertions(+), 2390 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/clkt_clksel.c
 delete mode 100644 arch/arm/mach-omap2/clkt_iclk.c
 delete mode 100644 arch/arm/mach-omap2/clock2430.c
 delete mode 100644 arch/arm/mach-omap2/clock2xxx.c
 delete mode 100644 arch/arm/mach-omap2/clock34xx.c
 delete mode 100644 arch/arm/mach-omap2/clock34xx.h
 delete mode 100644 arch/arm/mach-omap2/clock3517.c
 delete mode 100644 arch/arm/mach-omap2/clock3517.h
 delete mode 100644 arch/arm/mach-omap2/clock36xx.c
 delete mode 100644 arch/arm/mach-omap2/clock36xx.h
 delete mode 100644 arch/arm/mach-omap2/clock3xxx.c
 delete mode 100644 arch/arm/mach-omap2/clock44xx.h
 delete mode 100644 arch/arm/mach-omap2/clock_common_data.c
 create mode 100644 drivers/clk/ti/clkt_dflt.c
 rename {arch/arm/mach-omap2 => drivers/clk/ti}/clkt_dpll.c (94%)
 create mode 100644 drivers/clk/ti/clkt_iclk.c
 rename {arch/arm/mach-omap2 => drivers/clk/ti}/dpll3xxx.c (84%)
 rename {arch/arm/mach-omap2 => drivers/clk/ti}/dpll44xx.c (91%)
#1 lore raw
Quoted 6 lines · Tero Kristo

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

author
#2 lore raw
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Tero Kristo

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.

Quoted 1 line

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

Quoted 8 lines

Also, I just gave this branch a quick boot test and it seems to behave for me.

Regards,

Tony

#3 lore raw
Quoted 13 lines · Tero Kristo
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Tero Kristo

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.

Quoted 8 lines

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.

Quoted 4 lines
Quoted 1 line

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

#4 lore raw
Quoted 23 lines · Tony Lindgren
Quoted 13 lines · Tero Kristo
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Tero Kristo

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.

Quoted 8 lines

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.

Quoted 4 lines

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

author
#5 lore raw
Quoted 30 lines · Paul Walmsley
Quoted 23 lines · Tony Lindgren
Quoted 13 lines · Tero Kristo
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Tero Kristo

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.

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

#6 lore raw
In reply to Tony Lindgren

Quoting Tony Lindgren (2015-07-14 03:40:06)

Quoted 6 lines · Tero Kristo
Quoted 5 lines · Tony Lindgren
Quoted 4 lines · Tero Kristo
Quoted 3 lines

This pull request contains the TI clock driver set to move the clock implementations under clock driver. Some small portions of the clock =

driver

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

code still remain under mach-omap2 after this, it should be decided w=

hether

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

this code is now obsolete and should be deleted or should someone try=

to fix

Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
Quoted 1 line

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-om=

ap2,

Quoted 2 lines
Quoted 2 lines

they are DVFS related. OMAP3 core dvfs support is currently completely unused (this could probably be removed, or shall we re-introduce the pa=

inful

Quoted 1 line
Quoted 1 line

core dvfs at some point again?), and parts of the omap2 core dpll handl=

ing

Quoted 1 line
Quoted 1 line

code should probably be re-written; or at least verified that it actual=

ly

Quoted 1 line
Quoted 1 line

works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle =

with

Quoted 1 line
Quoted 1 line

it.... I could probably try to get some sort of DVFS test case to work =

on

Quoted 1 line
Quoted 1 line

the board farm OMAP2 board I have access to though, I can investigate t=

his.

Quoted 6 lines

=

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

Quoted 6 lines

=

Quoted 4 lines
Quoted 1 line

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 t=

his

Quoted 14 lines
Quoted 1 line

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw
In reply to Tero Kristo
Quoted 3 lines · Tero Kristo

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.

Quoted 4 lines

are available in the git repository at:

[email protected]: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<-----

include/linux/clk/ti.h +0 -0
diff --cc include/linux/clk/ti.h
index 448b4f87b9eb,f1838256fbaa..000000000000
drivers/clk/ti/clock.h +4 -12
index d4d232fd89bc..d8aafd333058 100644
@@ -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;
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#8 lore raw
Quoted 8 lines · Stephen Boyd
Quoted 4 lines · Tero Kristo

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....?

Quoted 8 lines
Quoted 5 lines

are available in the git repository at:

[email protected]: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.

Quoted 6 lines

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

Quoted 44 lines

----8<-----

include/linux/clk/ti.h +0 -0
diff --cc include/linux/clk/ti.h
index 448b4f87b9eb,f1838256fbaa..000000000000
drivers/clk/ti/clock.h +2 -6
index d4d232fd89bc..d8aafd333058 100644
@@ -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,

drivers/clk/ti/clock.h +2 -6
@@ -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;
#9 lore raw
Quoted 11 lines · Tero Kristo
Quoted 8 lines · Stephen Boyd
Quoted 4 lines · Tero Kristo

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

Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
author
#10 lore raw
Quoted 6 lines · Stephen Boyd
Quoted 5 lines · Tero Kristo
Quoted 4 lines · Stephen Boyd
Quoted 3 lines · Tero Kristo

The following changes since commit
bc0195aad0daa2ad5b0d76cce22b167bc3435590:

Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line

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