Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756807Ab3JKGzm (ORCPT ); Fri, 11 Oct 2013 02:55:42 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:53515 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753076Ab3JKGzk (ORCPT ); Fri, 11 Oct 2013 02:55:40 -0400 Message-ID: <5257A0C0.8000701@ti.com> Date: Fri, 11 Oct 2013 12:24:56 +0530 From: Kishon Vijay Abraham I User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nishanth Menon CC: Mark Rutland , dt list , Russell King - ARM Linux , Pawel Moll , "ijc+devicetree@hellion.org.uk" , Tony Lindgren , Stephen Warren , lkml , Rob Herring , Benoit Cousson , linux-omap , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1 References: <1381402195-29257-1-git-send-email-kishon@ti.com> <20131010141949.GA13277@kahuna> <52579723.6080209@ti.com> <5257A05B.2070906@ti.com> In-Reply-To: <5257A05B.2070906@ti.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3024 Lines: 68 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/