Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756082Ab0GNQrq (ORCPT ); Wed, 14 Jul 2010 12:47:46 -0400 Received: from eu1sys200aog101.obsmtp.com ([207.126.144.111]:54881 "EHLO eu1sys200aog101.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753187Ab0GNQrp (ORCPT ); Wed, 14 Jul 2010 12:47:45 -0400 Date: Wed, 14 Jul 2010 22:17:09 +0530 From: Sundar R IYER To: Mark Brown Cc: "lrg@slimlogic.co.uk" , "sameo@linux.intel.com" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , STEricsson_nomadik_linux , Linus WALLEIJ , Bengt JONSSON Subject: Re: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data Message-ID: <20100714164708.GD1689@bnru01.bnr.st.com> References: <20100713150814.GA13767@bnru01.bnr.st.com> <20100713150905.GD24626@rakim.wolfsonmicro.main> <20100713161343.GA25342@bnru01.bnr.st.com> <20100713203852.GA1756@rakim.wolfsonmicro.main> <20100714145053.GA1689@bnru01.bnr.st.com> <20100714145748.GF31073@rakim.wolfsonmicro.main> <20100714153643.GB1689@bnru01.bnr.st.com> <20100714154726.GH31073@rakim.wolfsonmicro.main> <20100714160941.GC1689@bnru01.bnr.st.com> <20100714162048.GA27512@rakim.wolfsonmicro.main> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100714162048.GA27512@rakim.wolfsonmicro.main> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2417 Lines: 44 > Are you positive that in your system it is sensible for consumers to > enable and disable all the supplies? Usually there are restrictions on > what can sensibly be done on a given system. For example, disabling the > CPU core or RAM supplies from software would normally not work terribly > well. As I said earlier, there are other supplies which I havent exposed here, simply because, 1. they are controlled out of the kernel, which makes it meaningless to include them for kernel modules 2. Even if those were included, the risk of mis-controlling them due to bad SW is very high as you say and hence safely out of SW control. I assure you that such supplies are *not* included in this list. > CPU core or RAM supplies from software would normally not work terribly Also, usually the deepest(lowest) power state for the CPU core is ~0V(atleast on our platform); which can be possible only by switching off the supplies to the core; thus effectively resulting in being controlled by SW. Further, I dont see the point of running full supplies to the RAM in a system idle state, when it is okay for the RAM to be powered @ a half rating OIW accountable to the idle state latencies. > Right, but think about the case I'm talking about: if you've only hooked > up some but not all of the consumers then the core has no idea about the > consumers you didn't hook up. You can only do power control when *all* > the consumers needed are configured. I see your point. But from an other perspective - it is *not* neccessary to have power control only when *all* consumers are in. For eg: we have 2 peripherals sharing one of the VAUX supplies. At this moment, both the peripherals drivers are integrated with the regulator APIs; which means the core handles most of the work regarding control. If, one of the peripherals isnt included in the final configuration, still, IMO, it *does* make sense that the other active peripheral optimally manage the supply control; which is gauranteed by the core. IOW & IMO, a consumer that hasnt hooked up to the regulator and thus is *aware* that it isnt sourced can be safely assumed to be non-existent. Regards, Sundar -- 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/