On 08/09/2022, 18:07, "Xiang Xiao" <xiaoxiang781...@gmail.com> wrote:
On Fri, Sep 9, 2022 at 12:19 AM TimH <t...@jti.uk.com.invalid> wrote:
>> unsigned int apply_uv; /* ?? SEE BELOW [1] */
>Yes, bool is more suitable than int for apply_uv.
Thanks for confirming/agreeing - once 11.0 is released and I rebase my own work
I'll do a PR to change this (and add comments to the driver files).
>>[2] It is not clear, either in Linux or Nuttx, what the "constraint
>>voltage" that is applied during init will be. Perhaps the NuttX intent is
-
>>or should be - to use an actual value here (hence the int?) which will be
>>applied during init IF "boot_on" is set on (suggesting it is a parameter
>>that should be passed TO the regulator register/init function not filled
in
>>BY it?
>
>
> boot_on in NuttX is simple, the common code will enable the regulator if
> boot_on is true otherwise disable it in regulaotr_register.
OK, makes sense, thanks.
> If this is all (nearly) correct, then I think the call to register a
> regulator
<snip>
Yes, I think so.
> If I'm nearly right I might add that I believe there are useful members of
> the regulator_desc_s structure missing, such as "active_discharge" that's
> useful for the ACT8945A.
<snip>
> The fields in regulator_desc_s are designed for the common regulator
> framework code, so it's better to put a new field to this struct if the
> common does the different action based on it. If the new info is only used
> by a specific driver, regulator_dev_s::priv is a better place.
The two I suggested are in the Linux spec and are common things for processor
PMICs. These would be good candidates to add to the common code I think.
>> Final observation - Linux documentation quite clearly states microvolts
>> for all voltage parameters.
<snip>
>
>
> The initial design follows Linux convention, that's why the field ends
with
> _uv not _mv.. uint32_t can hold 4293.967295V with uV which is enough in
> most case.
OK I will use uv. Think it might mean the AXP202 driver needs fixing...it is
using battery charger framework for regulator functions so someone probably
needs to revisit it at some point.
