[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5257A0C0.8000701@ti.com>
Date: Fri, 11 Oct 2013 12:24:56 +0530
From: Kishon Vijay Abraham I <kishon@...com>
To: Nishanth Menon <nm@...com>
CC: Mark Rutland <mark.rutland@....com>,
dt list <devicetree@...r.kernel.org>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Pawel Moll <pawel.moll@....com>,
"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
Tony Lindgren <tony@...mide.com>,
Stephen Warren <swarren@...dotorg.org>,
lkml <linux-kernel@...r.kernel.org>,
Rob Herring <rob.herring@...xeda.com>,
Benoit Cousson <bcousson@...libre.com>,
linux-omap <linux-omap@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: 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 <kishon@...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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists