Skip to contentSkip to conversation

ARM: OMAP2+: PM: core support for SMPS regulators for v3.4

GIT PULL Kevin Hilman 4 participants 14 messages Mar 7, 2012 – Apr 3, 2012

lore
Share & tools
lore

Kevin Hilman

author
#0 lore raw

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(-)
#1 lore raw
Quoted 10 lines · Kevin Hilman

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

author
#2 lore raw
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Kevin Hilman

Tony,

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

Quoted 7 lines
Quoted 5 lines

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

#3 lore raw
Quoted 16 lines · Kevin Hilman
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Kevin Hilman

Tony,

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

Quoted 7 lines
Quoted 5 lines

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?

Quoted 8 lines

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:

Quoted 8 lines · Mark Brown
Quoted 4 lines · Peter Ujfalusi

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

#4 lore raw
Quoted 13 lines · Tony Lindgren
Quoted 10 lines · Kevin Hilman

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

...

Quoted 2 lines

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120309/1cadb9fb/attachment-0001.sig>

author
#5 lore raw
Quoted 15 lines · Mark Brown
Quoted 6 lines · Tony Lindgren
Quoted 4 lines · Kevin Hilman

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

Quoted 7 lines
Quoted 5 lines

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:

Quoted 8 lines

...

Quoted 2 lines

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

Quoted 2 lines

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?

Quoted 2 lines

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

#6 lore raw
Quoted 6 lines · Kevin Hilman
Quoted 3 lines · Mark Brown

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?

Quoted 7 lines

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

Oh, ick. That really is quite buried and probably depends on some of the earlier changes too.

Quoted 5 lines
Quoted 2 lines

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?

The branch itself is essentially stable but I'm not enthused about the idea of merging the whole thing via the OMAP 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.

Quoted 6 lines
Quoted 2 lines

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120311/51f01c43/attachment-0001.sig>

author
#7 lore raw
Quoted 2 lines · Mark Brown

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.

Quoted 3 lines

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.

Quoted 14 lines
Quoted 6 lines
Quoted 2 lines

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.

Quoted 3 lines

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

Quoted 39 lines

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
#8 lore raw
Quoted 8 lines · Kevin Hilman
Quoted 2 lines · Mark Brown

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120312/b4b9e091/attachment-0001.sig>

author
#9 lore raw
Quoted 18 lines · Mark Brown
Quoted 8 lines · Kevin Hilman
Quoted 2 lines · Mark Brown

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.

Quoted 2 lines

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

OK.

Tony, updated pull request below. This includes all the TWL depencies merged from the 'topic/twl' tag in Mark's tree.

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 39358f2b57f37fe079eff4159307c844a0bfb176:

Merge branch 'pm-wip/smps-regulator' into for_3.4/pm/smps-regulator (2012-03-12 15:36:45 -0700)

----------------------------------------------------------------

Kevin Hilman (3):
ARM: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table Merge tag 'topic/twl' into for_3.4/pm/smps-regulator
Merge branch 'pm-wip/smps-regulator' into for_3.4/pm/smps-regulator

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 (6):
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
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 ++++
 arch/arm/mach-omap2/twl-common.c                   |  147 +++++++++
 arch/arm/mach-omap2/vc3xxx_data.c                  |    1 +
 arch/arm/mach-omap2/voltage.c                      |   21 +-
 drivers/mfd/twl-core.c                             |   41 ++-
 drivers/regulator/twl-regulator.c                  |  327 +++++++++++++++-----
 include/linux/i2c/twl.h                            |   14 +-
 7 files changed, 532 insertions(+), 87 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
#10 lore raw
Quoted 3 lines · Kevin Hilman

Tony, updated pull request below. ?This includes all the TWL depencies merged from the 'topic/twl' tag in Mark's tree.

Has this been lost now? It seems regulator parts got merged, but voltage parts are missing from Arnd's pull requests and are not showing up in linux-next.
Was looking forward for voltage control in 3.4 to achieve higher clock rates on our aging OMAP3 hardware.

Quoted 45 lines

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 39358f2b57f37fe079eff4159307c844a0bfb176:

?Merge branch 'pm-wip/smps-regulator' into for_3.4/pm/smps-regulator (2012-03-12 15:36:45 -0700)

----------------------------------------------------------------

Kevin Hilman (3):
? ? ?ARM: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table ? ? ?Merge tag 'topic/twl' into for_3.4/pm/smps-regulator
? ? ?Merge branch 'pm-wip/smps-regulator' into for_3.4/pm/smps-regulator

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 (6):
? ? ?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 ? ? ?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 ++++
?arch/arm/mach-omap2/twl-common.c ? ? ? ? ? ? ? ? ? | ?147 +++++++++
?arch/arm/mach-omap2/vc3xxx_data.c ? ? ? ? ? ? ? ? ?| ? ?1 +
?arch/arm/mach-omap2/voltage.c ? ? ? ? ? ? ? ? ? ? ?| ? 21 +-
?drivers/mfd/twl-core.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? 41 ++-
?drivers/regulator/twl-regulator.c ? ? ? ? ? ? ? ? ?| ?327 +++++++++++++++-----
?include/linux/i2c/twl.h ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? 14 +-
Quoted 6 lines

?7 files changed, 532 insertions(+), 87 deletions(-)
?create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

--
Gra?vydas

#11 lore raw
Quoted 10 lines · Grazvydas Ignotas
Quoted 3 lines · Kevin Hilman

Tony, updated pull request below. ?This includes all the TWL depencies merged from the 'topic/twl' tag in Mark's tree.

Has this been lost now? It seems regulator parts got merged, but voltage parts are missing from Arnd's pull requests and are not showing up in linux-next.
Was looking forward for voltage control in 3.4 to achieve higher clock rates on our aging OMAP3 hardware.

Sounds like this is something we should get merged early to arm-soc tree after the merge window.

Regards,

Tony

author
#12 lore raw
In reply to Grazvydas Ignotas
Quoted 8 lines · Grazvydas Ignotas
Quoted 3 lines · Kevin Hilman

Tony, updated pull request below. ?This includes all the TWL depencies merged from the 'topic/twl' tag in Mark's tree.

Has this been lost now? It seems regulator parts got merged, but voltage parts are missing from Arnd's pull requests and are not showing up in linux-next.

Not lost, just delayed. Due to problems in working out the
dependencies with the regulator core, this pull request was too late to make it for v3.4.

Kevin

#13 lore raw
In reply to Kevin Hilman
Quoted 20 lines · Kevin Hilman
Quoted 18 lines · Mark Brown
Quoted 8 lines · Kevin Hilman
Quoted 2 lines · Mark Brown

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.

Quoted 7 lines
Quoted 2 lines

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

OK.

Tony, updated pull request below. This includes all the TWL depencies merged from the 'topic/twl' tag in Mark's tree.

Pulled in this into pm-regulator branch finally.

Tony