Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757258AbcCaT7F (ORCPT ); Thu, 31 Mar 2016 15:59:05 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:19467 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752578AbcCaT7D (ORCPT ); Thu, 31 Mar 2016 15:59:03 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Thu, 31 Mar 2016 12:57:14 -0700 Message-ID: <56FD7F07.7010404@nvidia.com> Date: Fri, 1 Apr 2016 01:18:23 +0530 From: Laxman Dewangan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mark Brown CC: Bjorn Andersson , Bjorn Andersson , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Liam Girdwood , Stephen Warren , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Gandhar Dighe , Stuart Yates Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior References: <20160331165145.GF2350@sirena.org.uk> <56FD5A9F.5050001@nvidia.com> <20160331174741.GO2350@sirena.org.uk> <56FD62BA.3040406@nvidia.com> <20160331183130.GR2350@sirena.org.uk> <56FD6CF7.5080909@nvidia.com> <20160331184553.GS2350@sirena.org.uk> <56FD6ED6.3020507@nvidia.com> <20160331185945.GT2350@sirena.org.uk> <56FD7379.2000307@nvidia.com> <20160331192227.GU2350@sirena.org.uk> In-Reply-To: <20160331192227.GU2350@sirena.org.uk> X-Originating-IP: [10.19.65.30] X-ClientProxiedBy: DRUKMAIL102.nvidia.com (10.25.59.20) To bgmail102.nvidia.com (10.25.59.11) Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 990 Lines: 25 On Friday 01 April 2016 12:52 AM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Fri, Apr 01, 2016 at 12:29:05AM +0530, Laxman Dewangan wrote: >> On Friday 01 April 2016 12:29 AM, Mark Brown wrote: >> But here is the stuff without typo ;-) >> Device supports 5mV/us and 100mV/us which is not in observed value. > So why doesn't the device end up configuring 100mV/us when asked for > 50mv/us? That's reasonably expected - the configured ramp rate is a > maximum rate given that this is used to limit inrush current. > > We did this to adjust device configuration to nearest higher side but this is not working well on some of cases. On same device, DCDC (SD) rails support 4 ramp configurations, 13.75mV/us, 27.5mV/us, 55mV/us and 100mV/us. HW team measured the ramp time at 7.5mV/us when device configured at 27.5mV/uS. So as per above, it will be adjusted to 13.75mV/us (nearest higher side) for device configuration but this device need to configure for 27.5mV/us.