On Mon, Feb 18, 2019 at 03:28:46PM +0100, Krzysztof Kozlowski wrote: > On Mon, 18 Feb 2019 at 15:03, Torsten Duwe <d...@lst.de> wrote: > > > > > --- a/doc/device-tree-bindings/regulator/regulator.txt > > > +++ b/doc/device-tree-bindings/regulator/regulator.txt > > > @@ -35,6 +35,7 @@ Optional properties: > > > - regulator-max-microamp: a maximum allowed Current value > > > - regulator-always-on: regulator should never be disabled > > > - regulator-boot-on: enabled by bootloader/firmware > > > +- regulator-ramp-delay: ramp delay for regulator (in uV/us) > > > > I guess you mean s/V, not V/s; at least the code suggests so. > > uV/uS. It is correct in the code: > int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay); > delay = (uV - uV) / (uV / uS) = uS
You're right. _divide_ by that value; somhow this has escaped me. Sorry for the noise. nit: "s" is for seconds, "S" is for conductance. > > But my main point is: is the required delay always a linear > > function of the voltage jump? Depending on the dampening and > > load on the rail this could be an overshoot and settle, no? > > > > So I suggest to make that an array with 2 elements: a fixed part > > and a time per voltage change. Does that make sense? > > Just to make it clear - then we do not follow Linux kernel DT bindings. > The voltage change might have exponential characteristic and/or have > additional fixed delay time (see patch 7 here). We could re-use some > properties from Linux bindings for that purpose: > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L19 > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L24 I see. But then "static void regulator_set_value_delay(...)" should either at least have a "ramp" somewhere in its name or it should discover the device properties on its own, in order to be able to handle regulator-settling-time* and regulator-enable-ramp-delay as well in the future. (i.e. pass it uc_pdata instead of uc_pdata->ramp_delay and also let it handle the condition). Torsten _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot