Patchwork [GIT,PULL] ARM: OMAP2+: PM: core support for SMPS regulators for v3.4

login
register
mail settings
Submitter Kevin Hilman
Date March 7, 2012, 8:14 p.m.
Message ID <877gywjhht.fsf@ti.com>
Download mbox
Permalink /patch/145336/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/pm/smps-regulator

Comments

Kevin Hilman - March 7, 2012, 8:14 p.m.
Tony,

Please pull the following support for using regulators to control the
on-chip VC/VP managed voltage domains.

The regulator driver support for this is already queued in the regulator
tree, and this is the supporting core work.

This combined with the CPUfreq changes to use the regulator framework
will finally result in MPU DVFS working in mainline.

Kevin


The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:

  Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/pm/smps-regulator

for you to fetch changes up to c15f1d84bb3ddd668593e9bca53221a2f82e9e99:

  ARM: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table (2012-03-06 17:37:14 -0800)

----------------------------------------------------------------
Kevin Hilman (1):
      ARM: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table

Tero Kristo (4):
      arm: omap3: voltage: fix channel configuration
      arm: omap3: add common twl configurations for vdd1 and vdd2
      arm: omap3: twl: add external controllers for core voltage regulators
      arm: omap4: add common twl configurations for vdd1, vdd2 and vdd3

 arch/arm/mach-omap2/twl-common.c  |  147 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/vc3xxx_data.c |    1 +
 arch/arm/mach-omap2/voltage.c     |   21 +++++-
 3 files changed, 166 insertions(+), 3 deletions(-)
Tony Lindgren - March 8, 2012, 2:18 a.m.
* Kevin Hilman <khilman@ti.com> [120307 11:42]:
> Tony,
> 
> Please pull the following support for using regulators to control the
> on-chip VC/VP managed voltage domains.
> 
> The regulator driver support for this is already queued in the regulator
> tree, and this is the supporting core work.
> 
> This combined with the CPUfreq changes to use the regulator framework
> will finally result in MPU DVFS working in mainline.

Nice.. However this one might be missing some header changes?

I'm getting the following:

arch/arm/mach-omap2/twl-common.c:174:15: error: variable 'omap3_vdd1_drvdata' has initializer but incomplete type
arch/arm/mach-omap2/twl-common.c:175:2: error: unknown field 'get_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:175:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:175:2: warning: (near initialization for 'omap3_vdd1_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:176:2: error: unknown field 'set_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:176:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:176:2: warning: (near initialization for 'omap3_vdd1_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:179:15: error: variable 'omap3_vdd2_drvdata' has initializer but incomplete type
arch/arm/mach-omap2/twl-common.c:180:2: error: unknown field 'get_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:180:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:180:2: warning: (near initialization for 'omap3_vdd2_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:181:2: error: unknown field 'set_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:181:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:181:2: warning: (near initialization for 'omap3_vdd2_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c: In function 'omap3_pmic_get_config':
arch/arm/mach-omap2/twl-common.c:193:3: error: invalid use of undefined type 'struct twl_regulator_driver_data'
arch/arm/mach-omap2/twl-common.c:198:3: error: invalid use of undefined type 'struct twl_regulator_driver_data'
arch/arm/mach-omap2/twl-common.c: At top level:
arch/arm/mach-omap2/twl-common.c:400:15: error: variable 'omap4_vdd1_drvdata' has initializer but incomplete type
arch/arm/mach-omap2/twl-common.c:401:2: error: unknown field 'get_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:401:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:401:2: warning: (near initialization for 'omap4_vdd1_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:402:2: error: unknown field 'set_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:402:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:402:2: warning: (near initialization for 'omap4_vdd1_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:405:15: error: variable 'omap4_vdd2_drvdata' has initializer but incomplete type
arch/arm/mach-omap2/twl-common.c:406:2: error: unknown field 'get_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:406:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:406:2: warning: (near initialization for 'omap4_vdd2_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:407:2: error: unknown field 'set_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:407:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:407:2: warning: (near initialization for 'omap4_vdd2_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:410:15: error: variable 'omap4_vdd3_drvdata' has initializer but incomplete type
arch/arm/mach-omap2/twl-common.c:411:2: error: unknown field 'get_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:411:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:411:2: warning: (near initialization for 'omap4_vdd3_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c:412:2: error: unknown field 'set_voltage' specified in initializer
arch/arm/mach-omap2/twl-common.c:412:2: warning: excess elements in struct initializer [enabled by default]
arch/arm/mach-omap2/twl-common.c:412:2: warning: (near initialization for 'omap4_vdd3_drvdata') [enabled by default]
arch/arm/mach-omap2/twl-common.c: In function 'omap4_pmic_get_config':
arch/arm/mach-omap2/twl-common.c:425:3: error: invalid use of undefined type 'struct twl_regulator_driver_data'
arch/arm/mach-omap2/twl-common.c:431:3: error: invalid use of undefined type 'struct twl_regulator_driver_data'
arch/arm/mach-omap2/twl-common.c:435:16: error: 'struct twl4030_platform_data' has no member named 'vdd3'
arch/arm/mach-omap2/twl-common.c:437:3: error: invalid use of undefined type 'struct twl_regulator_driver_data'
arch/arm/mach-omap2/twl-common.c:438:12: error: 'struct twl4030_platform_data' has no member named 'vdd3'

Regards,

Tony
Kevin Hilman - March 8, 2012, 6:09 p.m.
Tony Lindgren <tony@atomide.com> writes:

> * Kevin Hilman <khilman@ti.com> [120307 11:42]:
>> Tony,
>> 
>> Please pull the following support for using regulators to control the
>> on-chip VC/VP managed voltage domains.
>> 
>> The regulator driver support for this is already queued in the regulator
>> tree, and this is the supporting core work.
>> 
>> This combined with the CPUfreq changes to use the regulator framework
>> will finally result in MPU DVFS working in mainline.
>
> Nice.. However this one might be missing some header changes?

Oh, that's because it depends on the regulator core changes that are in
Mark's regulator tree.  You need the for-next branch of :

git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

For this to compile correctly.

Sorry, I should've been more clear above about the build dependency.

Kevin
Tony Lindgren - March 9, 2012, 12:32 a.m.
* Kevin Hilman <khilman@ti.com> [120308 09:37]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Kevin Hilman <khilman@ti.com> [120307 11:42]:
> >> Tony,
> >> 
> >> Please pull the following support for using regulators to control the
> >> on-chip VC/VP managed voltage domains.
> >> 
> >> The regulator driver support for this is already queued in the regulator
> >> tree, and this is the supporting core work.
> >> 
> >> This combined with the CPUfreq changes to use the regulator framework
> >> will finally result in MPU DVFS working in mainline.
> >
> > Nice.. However this one might be missing some header changes?
> 
> Oh, that's because it depends on the regulator core changes that are in
> Mark's regulator tree.  You need the for-next branch of :
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> 
> For this to compile correctly.
> 
> Sorry, I should've been more clear above about the build dependency.

Hmm just checking.. Recently Mark replied to Peter:

* Mark Brown <broonie@opensource.wolfsonmicro.com> [120228 02:17]:
> On Tue, Feb 28, 2012 at 09:40:10AM +0200, Peter Ujfalusi wrote:
>
> > NOTE: this series has been generated agains Takashi's topic/asoc branch merged
> > with Mark's for-next branch since this series depends on changes in Marks'
> > branch, but not yet pulled by Takashi (snd_soc_add_dai_controls implementation
> > from Liam).
>
> Never base *anything* off my for-next branch, it gets rebuilt regularly.

So can you guys please confirm that if is indeed an immutable
commit to use as a base to merge in something?

Regards,

Tony
Mark Brown - March 9, 2012, 11:47 a.m.
On Thu, Mar 08, 2012 at 04:32:18PM -0800, Tony Lindgren wrote:
> * Kevin Hilman <khilman@ti.com> [120308 09:37]:
> > Tony Lindgren <tony@atomide.com> writes:

> > Oh, that's because it depends on the regulator core changes that are in
> > Mark's regulator tree.  You need the for-next branch of :

> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

> > For this to compile correctly.

> > Sorry, I should've been more clear above about the build dependency.

> Hmm just checking.. Recently Mark replied to Peter:

...

> So can you guys please confirm that if is indeed an immutable
> commit to use as a base to merge in something?

Absolutely not, the for-next branch is rebuilt frequently especially
since it includes stuff sent to Linus and he complained about bugfixes
merged up into development code.  What is the actual dependency here?
The topic branches are more or less static, though some more than
others.

In general you should warn people if you've got a dependency on their
tree, it makes life easier.
Kevin Hilman - March 9, 2012, 3:29 p.m.
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> On Thu, Mar 08, 2012 at 04:32:18PM -0800, Tony Lindgren wrote:
>> * Kevin Hilman <khilman@ti.com> [120308 09:37]:
>> > Tony Lindgren <tony@atomide.com> writes:
>
>> > Oh, that's because it depends on the regulator core changes that are in
>> > Mark's regulator tree.  You need the for-next branch of :
>
>> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
>
>> > For this to compile correctly.
>
>> > Sorry, I should've been more clear above about the build dependency.
>
>> Hmm just checking.. Recently Mark replied to Peter:
>
> ...
>
>> So can you guys please confirm that if is indeed an immutable
>> commit to use as a base to merge in something?
>
> Absolutely not, the for-next branch is rebuilt frequently especially
> since it includes stuff sent to Linus and he complained about bugfixes
> merged up into development code.  What is the actual dependency here?

The stuff is in your topic/drivers branch.  Specifically:

ed5da2a mfd: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS
77a3915 regulator: twl-regulator: Add fixed LDO for V1V8, V2V1 supply
d64214b regulator: twl: adapt twl-regulator driver to dt
3e1ff1f regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
1a4a805 regulator: twl4030: add support for external voltage get/set

> The topic branches are more or less static, though some more than
> others.

Is topic/drivers something stable?  If not, these are a ways back in
that branch, maybe you make a topic/drivers-stable for us?

> In general you should warn people if you've got a dependency on their
> tree, it makes life easier.

Yeah, I should've raised this when the original series were posted.  The
arch stuff and drivers/regulator stuff were posted all together, but you
picked out the regulator stuff and I picked up the rest.  

Kevin
Kevin Hilman - March 12, 2012, 5:26 p.m.
Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> The branch itself is essentially stable but I'm not enthused about the
> idea of merging the whole thing via the OMAP tree.  

Right, I wasn't suggesting we merge it via OMAP tree.   I was just
looking for a stable point we could use as s dependency when merging
everything together for the arm-soc tree.

> However, as Linus has released an -rc7 I should pull some stuff out of
> there and send fixes to him so I've created a topic/twl so let's just
> rebase.

OK.

>> > In general you should warn people if you've got a dependency on their
>> > tree, it makes life easier.
>
>> Yeah, I should've raised this when the original series were posted.  The
>> arch stuff and drivers/regulator stuff were posted all together, but you
>> picked out the regulator stuff and I picked up the rest.  
>
> Actually IIRC by the time I applied this the ARM changes had been
> totally deteched from the regulator stuff - Tero was sending just the
> regulator patch by itself and I actually applied the patch it was part
> of a twl regulator series Rajendra put together after I got fed up with
> the number of people sending me incompatible changes without talking to
> each other.  I'd completely forgotten about any arch/arm stuff.
>
> This sort of issue is becoming far too common with the OMAP stuff, there
> needs to be a much greater awareness of the need to coordinate both
> between trees and with multiple people working on the same code.

Completely agree, hence this email trying to work this out before the
merge window.

Thanks for this topic branch.  We'll ask for it to be included as a
branch in arm-soc/depends/* so that OMAP voltage core changes will build
there as well as in linux-next.

Thanks,

Kevin


> The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
>
>   Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/topic/twl
>
> for you to fetch changes up to 46eda3e96a65b378041c79c51ff2e02009f7e2d0:
>
>   mfd: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS (2012-03-11 20:09:26 +0000)
>
> ----------------------------------------------------------------
> TWL specific changes, cross-merged with OMAP due to arch/arm wanting to
> use the new ability to override the voltage set and get operations to
> support the in-CPU voltage management.  The other changes are minor
> fixes, the addition of a few new regulators and device tree support.
>
> ----------------------------------------------------------------
> Laxman Dewangan (1):
>       regulator: twl6030: Fix voltage selection logic
>
> Peter Ujfalusi (2):
>       regulator: twl-regulator: Add fixed LDO for V1V8, V2V1 supply
>       mfd: twl-core: regulator configuration for twl6030 V1V8, V2V1 SMPS
>
> Rajendra Nayak (1):
>       regulator: twl: adapt twl-regulator driver to dt
>
> Tero Kristo (2):
>       regulator: twl4030: add support for external voltage get/set
>       regulator: twl6030: add support for vdd1, vdd2 and vdd3 regulators
>
>  .../bindings/regulator/twl-regulator.txt           |   68 ++++
>  drivers/mfd/twl-core.c                             |   41 +++-
>  drivers/regulator/twl-regulator.c                  |  327 +++++++++++++++-----
>  include/linux/i2c/twl.h                            |   14 +-
>  4 files changed, 366 insertions(+), 84 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
Mark Brown - March 12, 2012, 5:32 p.m.
On Mon, Mar 12, 2012 at 10:26:53AM -0700, Kevin Hilman wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:

> > The branch itself is essentially stable but I'm not enthused about the
> > idea of merging the whole thing via the OMAP tree.  

> Right, I wasn't suggesting we merge it via OMAP tree.   I was just
> looking for a stable point we could use as s dependency when merging
> everything together for the arm-soc tree.

Well, if you don't base the OMAP changes that depend on it off the
regulator changes then you'll break bisection as you'll have a bunch of
commits which won't have all their dependencies present on a branch
(since they're not present in the branch point and aren't otherwise
merged in), if bisect goes down that branch it'll be miserable.  That
seems bad and while I've not run into it with OMAP in particular it's
rather painful when it does happen.

It's much better if the branch has the required changes merged into it
prior to their being used.