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]
Date:	Mon, 29 Feb 2016 09:47:51 -0800
From:	Bjorn Andersson <bjorn.andersson@...aro.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	broonie@...nel.org, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	lgirdwood@...il.com, bjorn.andersson@...ymobile.com,
	swarren@...dotorg.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based
 on platform behavior

On Mon 29 Feb 06:40 PST 2016, Laxman Dewangan wrote:

> It is observed that voltage change in given rail affected by the load
> and the capacitor in the rail. This may cause the slow ramp in voltage
> against what PMIC has programmed.
> 
> The property regulator-ramp-delay provides the ramp delay configuration
> for PMIC but actual voltage settling time may change based on platform.
> 
> Add new property "regulator-ramp-delay-scale" for platform specific scaling
> in final ramp delay calculation. On this case, final wait delay time
> for voltage change is calculated as the
>    DIV_ROUND_UP(ramp_delay * ramp_delay_scale, 100)
> 
> The value is provided in the term of percentage i.e. 300% means it will
> do the 3x delay of calculated value.
> 
> Signed-off-by: Laxman Dewangan <ldewangan@...dia.com>
> ---

The regulator-ramp-delay is a variable you can tweak on a board basis,
so I'm not sure what benefit it gives to be able to add a scaling
factor to this.

In my experience your HW engineer will say "you have to wait X ms", not
"you have to wait 125% of X ms".


Can you please elaborate on why the original knob isn't sufficient?

Regards,
Bjorn

>  Documentation/devicetree/bindings/regulator/regulator.txt | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> index 1d112fc..f2e8360 100644
> --- a/Documentation/devicetree/bindings/regulator/regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -16,6 +16,13 @@ Optional properties:
>  - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
>    For hardware which supports disabling ramp rate, it should be explicitly
>    initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
> +- regulator-ramp-delay-scale: Platform specific scaling in ramp delay to
> +  provide extra guard time to settle down voltage after its change. This will
> +  help to wait for extra time for voltage settling based on platform behavior.
> +  This is provided in terms of percentage scaling like 300% means final delay
> +  will become 3x of calculated ramp delay for voltage change.
> +  The final delay is calculated as:
> +	delay = DIV_ROUND_UP(ramp-delay * ramp-delay-scale, 100)
>  - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply
>    rail to reach the target voltage, plus/minus whatever tolerance the board
>    design requires. This property describes the total system ramp time
> -- 
> 2.1.4
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ