How to handle quirky behavior with boards.

How to handle quirky behavior with boards.

[Olliver Schinagl]

Hey all,

We found a bug in the design of a board that we use. This board (Olimex 
OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that 
needs special treatment.

The bug is, that there is too much capacitance on the output of LDO3, 
which causes the PMIC to shutdown when enabeling LDO3.

The AXP does have voltage ramp control for LDO3, but this is only 
effective After LDO3 has been enabled.

To be able to turn on LDO3, we have to first set its voltage to the 
lowest setting (0.7 V), wait 1 ms, then turn it on. After that the 
voltage can be changed normally.

I'm already working on the patches to add the voltage ramp control but 
as described above, this will not fix the problem here.

My guess, and hence the question, is that we will need to add support 
for this quirk in the AXP209 LDO3 enable case. There are no quirk flags 
that I could find yet, so how is this preferabbly handled? A board level 
flag in the dts? AXP-level flag? Or is the soft-start flag sort of 
inteded for this? e.g. set soft-start for ldo3 in the dts, check this 
flag in the enable function and do the earlier described start-up?

Thanks,

Olliver

Re: How to handle quirky behavior with boards.

[Olliver Schinagl]

Hey all,

Sorry for top-posting, but I did not want to break the thread, while the 
initial mail does provide background information.

So I've implemented a software-based soft-start in the regulator_enable 
function of the axp209. This works as expected. Whether it is the right 
solution I'll happily debate with the patch-set I'm about to send.

The question that remains however, is how is voltage ramping supposed to 
work?

Right now, the core checks and setups various constraints. Two which are 
somewhat in conflicting order are:

regulator-always-on

and

ramp-delay.

If, for reasons outside of our control the regulator was not on during 
boot (miss-configured u-boot) but we want it to be always-on from the 
kernel side of things, we run into a problem, because the kernel turns 
the regulator on first (because of regulator-always-on) and only then 
sets its constraints.

Now we could in our specific case, tell the driver to check for the 
ramp-delay constraint, and then run it during init/probe, but that feels 
a little bit like a hack.

So my question is, what is there against moving some of the constrants 
before the always-on, so that the enable can atleast function properly 
according to its parameters?

Olliver

On 01-03-17 14:58, Olliver Schinagl wrote:
> Hey all,
>
> We found a bug in the design of a board that we use. This board (Olimex
> OLinuXino Lime2) features a PMIC (AXP209) and has an LDO, LDO3, that
> needs special treatment.
>
> The bug is, that there is too much capacitance on the output of LDO3,
> which causes the PMIC to shutdown when enabeling LDO3.
>
> The AXP does have voltage ramp control for LDO3, but this is only
> effective After LDO3 has been enabled.
>
> To be able to turn on LDO3, we have to first set its voltage to the
> lowest setting (0.7 V), wait 1 ms, then turn it on. After that the
> voltage can be changed normally.
>
> I'm already working on the patches to add the voltage ramp control but
> as described above, this will not fix the problem here.
>
> My guess, and hence the question, is that we will need to add support
> for this quirk in the AXP209 LDO3 enable case. There are no quirk flags
> that I could find yet, so how is this preferabbly handled? A board level
> flag in the dts? AXP-level flag? Or is the soft-start flag sort of
> inteded for this? e.g. set soft-start for ldo3 in the dts, check this
> flag in the enable function and do the earlier described start-up?
>
> Thanks,
>
> Olliver

Re: How to handle quirky behavior with boards.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Fri, Mar 03, 2017 at 04:31:43PM +0100, Olliver Schinagl wrote:

> So my question is, what is there against moving some of the constrants
> before the always-on, so that the enable can atleast function properly
> according to its parameters?

No, and in general please don't ask to send patches - just send patches
with any explanation/discussion in the cover letter and/or commit log.
That tends to make things go faster as the code can make any issues more
obvious and if there's no problem then patches can just be applied
immediately.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]