Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on fromsmps10_out1

[Kishon Vijay Abraham I]

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