Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Friday 18 October 2013 01:39 AM, Benoit Cousson wrote: Hi Kishon, On 16/10/2013 15:27, Nishanth Menon wrote: On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote: Benoit, On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote: smps10 should be enabled only in the case of host mode. So stop doing always_on, boot_on from smps10_out1. The driver will enable it in host mode. Can you take this patch too? Acked-by: Nishanth Menon n...@ti.com I've just applied it. Thanks :-) -Kishon Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
Hi Kishon, On 16/10/2013 15:27, Nishanth Menon wrote: On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote: Benoit, On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote: smps10 should be enabled only in the case of host mode. So stop doing always_on, boot_on from smps10_out1. The driver will enable it in host mode. Can you take this patch too? Acked-by: Nishanth Menon n...@ti.com I've just applied it. Thanks, Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
Benoit,
On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Can you take this patch too?
Thanks
Kishon
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
- regulator-always-on;
- regulator-boot-on;
};
ldo1_reg: ldo1 {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On 10/16/2013 08:17 AM, Kishon Vijay Abraham I wrote:
Benoit,
On Thursday 10 October 2013 04:19 PM, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Can you take this patch too?
Acked-by: Nishanth Menon n...@ti.com
Thanks
Kishon
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
-regulator-always-on;
-regulator-boot-on;
};
ldo1_reg: ldo1 {
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Thursday 10 October 2013 07:49 PM, Nishanth Menon wrote:
On 16:19-20131010, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
-regulator-always-on;
-regulator-boot-on;
};
ldo1_reg: ldo1 {
--
Always good to get rid of regulator-always-on. Thanks for it.
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
Hope this helps. Let me know if I misunderstood something here.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
The comment you just quoted tells it enables the regulator if its not enabled
by hardware. If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied. At-least that's what
I understood from that comment.
Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the
palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This
should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
The comment you just quoted tells it enables the regulator if its not enabled
by hardware. If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied. At-least that's
what
I understood from that comment.
Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.
btw.. I think this is the code in regulator fw that's responsible for enabling..
/* If the constraints say the regulator should be on at this point
* and we have control then make sure it is enabled.
*/
if ((rdev-constraints-always_on || rdev-constraints-boot_on)
ops-enable) {
ret = ops-enable(rdev);
if (ret 0) {
rdev_err(rdev, failed to enable\n);
goto out;
}
}
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Fri, Oct 11, 2013 at 1:54 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the
palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This
should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept
here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
The comment you just quoted tells it enables the regulator if its not enabled
by hardware. If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied. At-least that's
what
I understood from that comment.
Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.
btw.. I think this is the code in regulator fw that's responsible for
enabling..
/* If the constraints say the regulator should be on at this point
* and we have control then make sure it is enabled.
*/
if ((rdev-constraints-always_on || rdev-constraints-boot_on)
ops-enable) {
ret = ops-enable(rdev);
if (ret 0) {
rdev_err(rdev, failed to enable\n);
goto out;
}
}
Drat, you are right, I did not really dig deep. thanks for correcting
my understanding here.
I propose the following change in binding as it seems completely
misleading to me.
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f09..d999f096 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -8,7 +8,9 @@ Optional properties:
- regulator-min-microamp: smallest current consumers may set
- regulator-max-microamp: largest current consumers may set
- regulator-always-on: boolean, regulator should never be disabled
-- regulator-boot-on: bootloader/firmware enabled regulator
+- regulator-boot-on: regulator is enabled when the system is initially started.
+ If the regulator is not enabled by the hardware or bootloader then it will be
+ enabled when the constraints are applied.
- regulator-allow-bypass: allow the regulator to go into bypass mode
- name-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On 16:19-20131010, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
- regulator-always-on;
- regulator-boot-on;
};
ldo1_reg: ldo1 {
--
Always good to get rid of regulator-always-on. Thanks for it.
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
Hence Nak.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
