linux-kernel - Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56FD62BA.3040406@nvidia.com>
Date:	Thu, 31 Mar 2016 23:17:38 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nel.org>
CC:	Bjorn Andersson <bjorn@...o.se>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Liam Girdwood <lgirdwood@...il.com>,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Stephen Warren <swarren@...dotorg.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gandhar Dighe <gdighe@...dia.com>,
	Stuart Yates <syates@...dia.com>
Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based
 on platform behavior

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.