+Olof On 3 September 2015 at 08:50, Kishon Vijay Abraham I <kishon@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
