Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757546AbcCaR6S (ORCPT ); Thu, 31 Mar 2016 13:58:18 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:17285 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753533AbcCaR6R (ORCPT ); Thu, 31 Mar 2016 13:58:17 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Thu, 31 Mar 2016 10:56:57 -0700 Message-ID: <56FD62BA.3040406@nvidia.com> Date: Thu, 31 Mar 2016 23:17:38 +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 , Bjorn Andersson , 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: <56D65F7E.3090907@nvidia.com> <20160302043506.GC18327@sirena.org.uk> <56E81103.8010903@nvidia.com> <56ED0F58.7060005@nvidia.com> <56FBD4A3.7080208@nvidia.com> <20160330181623.GQ2350@sirena.org.uk> <56FCCC60.3080303@nvidia.com> <20160331165145.GF2350@sirena.org.uk> <56FD5A9F.5050001@nvidia.com> <20160331174741.GO2350@sirena.org.uk> In-Reply-To: <20160331174741.GO2350@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: 1867 Lines: 40 On Thursday 31 March 2016 11:17 PM, Mark Brown wrote: > * PGP Signed by an unknown key > > On Thu, Mar 31, 2016 at 10:43:03PM +0530, Laxman Dewangan wrote: > >> We need two properties, one what we measured in platform and second one for >> what we want to program PMIC. This is for the case where vendor advertised >> ramp delay is not same as measured due to platform design. > What makes you say that we need two properties? > >> Based on discussion, regulator-ramp-delay is for measured ramp delay in >> platform. So we will need another property for configuring PMIC. > So as well as delaying in the kernel to cover the ramp time you want to > configure something in the PMIC? What are you trying to configure in > the PMIC? How will the PMIC driver meaningfully interpret a generic > property given that the whole point here is that the PMIC is unable to > deliver in spec behaviour? > Here is the case, PMIC supports 2 ramp time configurations 5mv/us and 100mV/us. This is supported with some specific capacitance in rail output per recommendation from PMIC Vendor. This recommendation is generic in nature. We got PMIC with some non-desired default configuration i.e. 5mV/us. Our HW team recommend to configure the PMIC for 100mV/us. HW and chip team did simulation with tegra and PMIC and found that the board needs more capacitance then what Vendor recommended for proper signal conditioning on interface. So they put the difference capactitance value and this causes deviation in ramp delay from advertised value. In out design, we measured the ramp time as 50mv/us when PMIC is configured for 100mV/us. So for all settling time, we need to use the ramp as 50mV/us. From DT, I will provide regulator-ramp-delay as 50mv/us. But I do not have property for saying 100mv/us for PMIC configurations and this is what makes need of 2nd property.