From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756309AbbCXRTb (ORCPT ); Tue, 24 Mar 2015 13:19:31 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:48883 "EHLO opensource.wolfsonmicro.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755950AbbCXRT2 (ORCPT ); Tue, 24 Mar 2015 13:19:28 -0400 Date: Tue, 24 Mar 2015 17:19:25 +0000 From: Charles Keepax To: Mark Brown Cc: lgirdwood@gmail.com, linux-kernel@vger.kernel.org, patches@opensource.wolfsonmicro.com Subject: Re: [PATCH] regulator: arizona-ldo1: Add ramp time for HI_PWR Message-ID: <20150324171925.GL23705@opensource.wolfsonmicro.com> References: <1427207276-28038-1-git-send-email-ckeepax@opensource.wolfsonmicro.com> <20150324160609.GD17265@sirena.org.uk> <20150324164050.GI23705@opensource.wolfsonmicro.com> <20150324170554.GP17265@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150324170554.GP17265@sirena.org.uk> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 24, 2015 at 10:05:54AM -0700, Mark Brown wrote: > On Tue, Mar 24, 2015 at 04:40:50PM +0000, Charles Keepax wrote: > > On Tue, Mar 24, 2015 at 09:06:09AM -0700, Mark Brown wrote: > > > > So changes to move to the top voltage always take constant time while > > > all other voltage changes are instantaneous? That doesn't seem right. > > > I'd expect something more like a calculation based on some number of > > > miliseconds per milivolt. > > > Its more just that this is the only case that we really care > > about. The reg only ever gets used at 1.2V and 1.8V, and the > > only case where there is a problem is if we ask for 1.8V and > > we don't have it yet. > > > I don't think we really have the data to give for other cases. I > > could expand the comment perhaps? Or TBH it is fast enough it is > > unlikely to ever be a problem in practice so we could just drop > > the patch. > > You'll probably find that the ramp is pretty much linear so just > changing to something that multiplies out to the expected value will be > good enough. I'd rather not have bad examples that other drivers might > copy. Cool, I will respin. Thanks, Charles