From patchwork Fri Oct 11 07:27:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Nishanth Menon X-Patchwork-Id: 3021261 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B761B9F243 for ; Fri, 11 Oct 2013 07:27:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A83BF20322 for ; Fri, 11 Oct 2013 07:27:54 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 501F020320 for ; Fri, 11 Oct 2013 07:27:53 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VUX8K-0007Ez-59; Fri, 11 Oct 2013 07:27:36 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VUX8B-0007DN-43; Fri, 11 Oct 2013 07:27:27 +0000 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VUX88-0007BB-3D for linux-arm-kernel@lists.infradead.org; Fri, 11 Oct 2013 07:27:24 +0000 Received: by mail-wg0-f43.google.com with SMTP id b13so93988wgh.22 for ; Fri, 11 Oct 2013 00:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=TRkBCMMuxSyFZTgQnMfNU0m7+QbCajOvO/tfa1HdU3M=; b=Cg9UAIMYJHOODZxxH68+xQFOEEoSLwe4BS25Udbz9ZBp2YJJzqKtwdqgb2ibGN8sln Ng74QAcu7NAzbRoqYfBLuNAgoGtFZuA7oVXaxzcmPrFvaOWuDzB/+Zql/iz5XptAZ++i NwBosN9nOG+QoLvkkDPomKS4rpUeUwtNHZCaXrUObmxq8j4ydatlI2MFwnFviw2ednD+ Lcxaf2QEJ/DndosYTPk/S5N+fsGmRBm0wBh1I9ZdzRexHIsbqAEeAIzFRuj1NLAZW48b jHZaPochlM3ubUTPZIYtRI4LSTs6BIBle/0XMabKEN2u74PjwlHqEB8FIHqx+fhxQlty Inhw== MIME-Version: 1.0 X-Received: by 10.194.109.68 with SMTP id hq4mr16004454wjb.12.1381476422270; Fri, 11 Oct 2013 00:27:02 -0700 (PDT) Received: by 10.216.209.77 with HTTP; Fri, 11 Oct 2013 00:27:02 -0700 (PDT) In-Reply-To: <5257A0C0.8000701@ti.com> References: <1381402195-29257-1-git-send-email-kishon@ti.com> <20131010141949.GA13277@kahuna> <52579723.6080209@ti.com> <5257A05B.2070906@ti.com> <5257A0C0.8000701@ti.com> Date: Fri, 11 Oct 2013 02:27:02 -0500 X-Google-Sender-Auth: TJn5X7kQu56yLIA42sdRGAI5KrQ Message-ID: Subject: Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1 From: Nishanth Menon To: Kishon Vijay Abraham I X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20131011_032724_278467_9C02117B X-CRM114-Status: GOOD ( 27.14 ) X-Spam-Score: -1.9 (-) 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" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Oct 11, 2013 at 1:54 AM, Kishon Vijay Abraham I 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 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 - -supply: phandle to the parent supply/regulator node - regulator-ramp-delay: ramp delay for regulator(in uV/uS)