[GIT PULL] clk: ti: clock driver code migration to drivers

[GIT PULL] clk: ti: clock driver code migration to drivers

[Tero Kristo]

The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:

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

are available in the git repository at:

   git@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 => 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%)

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tony Lindgren]

* Tero Kristo <t-kristo@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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tero Kristo]

On 07/14/2015 12:54 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@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
>

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [150714 03:34]:
> On 07/14/2015 12:54 PM, Tony Lindgren wrote:
> >* Tero Kristo <t-kristo@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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Paul Walmsley]

On Tue, 14 Jul 2015, Tony Lindgren wrote:

> * Tero Kristo <t-kristo@ti.com> [150714 03:34]:
> > On 07/14/2015 12:54 PM, Tony Lindgren wrote:
> > >* Tero Kristo <t-kristo@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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tero Kristo]

On 07/16/2015 04:51 AM, Paul Walmsley wrote:
> On Tue, 14 Jul 2015, Tony Lindgren wrote:
>
>> * Tero Kristo <t-kristo@ti.com> [150714 03:34]:
>>> On 07/14/2015 12:54 PM, Tony Lindgren wrote:
>>>> * Tero Kristo <t-kristo@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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Michael Turquette]

Quoting Tony Lindgren (2015-07-14 03:40:06)
> * Tero Kristo <t-kristo@ti.com> [150714 03:34]:
> > On 07/14/2015 12:54 PM, Tony Lindgren wrote:
> > >* Tero Kristo <t-kristo@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 w=
hether
> > >>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-om=
ap2,
> > 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
> > core dvfs at some point again?), and parts of the omap2 core dpll handl=
ing
> > code should probably be re-written; or at least verified that it actual=
ly
> > 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 t=
his.
> =

> 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 t=
his
> > 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 majordomo@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

[Stephen Boyd]

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:
>
>   git@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..000000000000
--- 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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tero Kristo]

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:
>>
>>   git@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..000000000000
> --- 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;
>
>

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Stephen Boyd]

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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tero Kristo]

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