Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1218072 > unrolled thread

[PATCH v2 0/6] regulator: Fix pbias regulator enable

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/6] regulator: Fix pbias regulator enable Kishon Vijay Abraham I <kishon@ti.com> - 2015-09-03 09:00 +0200
    [PATCH v2 4/6] ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias Kishon Vijay Abraham I <kishon@ti.com> - 2015-09-03 09:00 +0200
    Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable Ulf Hansson <ulf.hansson@linaro.org> - 2015-09-03 09:40 +0200
      Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable Kishon Vijay Abraham I <kishon@ti.com> - 2015-09-03 11:30 +0200
        Re: [PATCH v2 0/6] regulator: Fix pbias regulator enable Tony Lindgren <tony@atomide.com> - 2015-09-03 17:10 +0200

#1218072 — [PATCH v2 0/6] regulator: Fix pbias regulator enable

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1218074 — [PATCH v2 4/6] ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias

Use "ti,pbias-omap3" compatible string which is specifically added
for OMAP3.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/dts/omap3.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..9af9ae1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -203,7 +203,7 @@
 		};
 
 		pbias_regulator: pbias_regulator {
-			compatible = "ti,pbias-omap";
+			compatible = "ti,pbias-omap3", "ti,pbias-omap";
 			reg = <0x2b0 0x4>;
 			syscon = <&scm_conf>;
 			pbias_mmc_reg: pbias_mmc_omap2430 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218077

+Olof

On 3 September 2015 at 08:50, Kishon Vijay Abraham I <kishon@ti.com> 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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218120

Hi,

On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote:
> +Olof
> 
> On 3 September 2015 at 08:50, Kishon Vijay Abraham I <kishon@ti.com> 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.

I generally perform my tests with omap2plus_defconfig and without this
series MMC doesn't work with omap2plus_defconfig.
> 
> Kishon, could you please clarify if $subject patchset solves that
> regression reported by Olof? Or perhaps Olof can run a test?

Just checked multi_v7_defconfig and this series is definitely required
to get MMC working. But we also have to enable 'CONFIG_REGULATOR_PBIAS'
which is not enabled by default in multi_v7_defconfig.

So we should have a patch to enable 'CONFIG_REGULATOR_PBIAS' in
multi_v7_defconfig to completely solve the problem reported by Olof.
I'll prepare a patch for multi_v7_defconfig and post it asap.

Thanks
Kishon

> 
> 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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218318

* Kishon Vijay Abraham I <kishon@ti.com> [150903 02:25]:
> On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote:
> > 
> > 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.

That works for me too. Or Mark can set up an immutable signed
branch that you can merge in, up to you guys.

It's still going to break git bisect for booting but
removes the regression when mergeing to mainline.

I'd squash all the one liner dts changes into a single
patch though when applying to cut down on the commit
noise.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web