Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756870Ab3JKGa4 (ORCPT ); Fri, 11 Oct 2013 02:30:56 -0400 Received: from mail-we0-f170.google.com ([74.125.82.170]:54295 "EHLO mail-we0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570Ab3JKGay convert rfc822-to-8bit (ORCPT ); Fri, 11 Oct 2013 02:30:54 -0400 MIME-Version: 1.0 In-Reply-To: <52579723.6080209@ti.com> References: <1381402195-29257-1-git-send-email-kishon@ti.com> <20131010141949.GA13277@kahuna> <52579723.6080209@ti.com> Date: Fri, 11 Oct 2013 01:30:52 -0500 X-Google-Sender-Auth: 3KwZ96kObU_v2KH96_ybkuHJ1o0 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 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" 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: 1895 Lines: 41 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. 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-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/