+Olof

On 3 September 2015 at 08:50, Kishon Vijay Abraham I [off-list ref] wrote:

vsel_reg and enable_reg of the pbias regulator descriptor should actually
have the offset from syscon.

However after
"ARM: dts: <platform>: add minimal l4 bus layout with control module
support"
vsel_reg and enable_reg started to have the absolute address because
of address translation that happens due to pbias node made as the
child node of syscon. This breaks the pbias regulator enable.

This series adds the 'offset' to be populated in vsel_reg and enable_reg
in the pbias driver itself.

Changes from v1:
*) Fixed Tony's review comments on adding a 'comment' for adding offset in
   the driver and adding a warning for using platform_get_resource.
*) Added Tony's Acked-by.

Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
dra72 and omap5 uevm

Kishon Vijay Abraham I (6):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
  ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
  ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
  ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
  ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias

 .../bindings/regulator/pbias-regulator.txt         |    7 ++-
 arch/arm/boot/dts/dra7.dtsi                        |    2 +-
 arch/arm/boot/dts/omap2430.dtsi                    |    2 +-
 arch/arm/boot/dts/omap3.dtsi                       |    2 +-
 arch/arm/boot/dts/omap4.dtsi                       |    2 +-
 arch/arm/boot/dts/omap5.dtsi                       |    2 +-
 drivers/regulator/pbias-regulator.c                |   56 +++++++++++++++++---
 7 files changed, 61 insertions(+), 12 deletions(-)

--
1.7.9.5

I have recently queued another patchset [1] for the mmc omap driver
for 4.3 through my mmc tree for which Olof Johansson reported a
regression [2] for Panda ES with multi_v7_defconfig.

Kishon, could you please clarify if $subject patchset solves that
regression reported by Olof? Or perhaps Olof can run a test?

Finally, perhaps it's better if we queue this through my mmc tree
since we would then be able to avoid the regression - if I put
$subject patchset before [1], right? Then I need an ack from Mark for
the regulator patch.
Please tell me if you guys prefer another way.

Kind regards
Uffe

[1]
http://permalink.gmane.org/gmane.linux.kernel/2027789

[2]
http://www.spinics.net/lists/linux-mmc/msg33146.html