| Message ID | 877gywjhht.fsf@ti.com |
|---|---|
| State | New |
| Headers | show |
* 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
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
* 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
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.
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
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
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.
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(-)