Re: short-circuit and over-current IRQs

[AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>]

Il 27/01/21 13:56, Matti Vaittinen ha scritto:
> Hello Mark,
> 

Hey Matti, hey Mark!

> Nice to hear from you. :)
> 
> On Wed, 2021-01-27 at 12:27 +0000, Mark Brown wrote:
>> On Wed, Jan 27, 2021 at 12:01:55PM +0000, Vaittinen, Matti wrote:
>>
>>> Anyways - I was wondering if this is common thing amongst many
>>> PMICs?
>>> If yes - then, perhaps some generally useful regulator helper could
>>> be
>>> added to help implementing the IRQ disabling + scheduling worker to
>>> check status and re-enable IRQs? I think it *might* save some time
>>> in
>>> the future - and help making same mistakes many times :]
>>

It's probably worth it if more drivers need that: sometimes there is
HW supporting this feature and it doesn't get done because of the usual
lack of time.

Providing a helper would probably help.

>> If we've got two that's enough for a helper.  TBH I'm a bit surprised
>> that people are implementing hardware that leaves the outputs enabled
>> when it detects this sort of error, it's something that's usually an
>> emergency that needs shutting off quickly to prevent hardware damage.
> 
> I can only speak for BD9576MUF - which has two limits for monitored
> entity (temperature/voltage). One limit being 'warning' limit (or
> 'detection' as data-sheet says), the other being 'protection' limit.
> 
> I don't know guys who designed HW - I am located to a remote spot on
> the other side of the world and on top of that I am the odd "SW guy" so
> it's better to keep me out of the HW R&D decisions and especially the
> customers ;) - but I *guess* the idea has been that consumer driver(s)
> could do some 'recovery action' at 'warning' limit (which might make
> sense for example when temperature is increased to 'high' but not yet
> 'damaging' - I guess there is something that can be done with
> over/under voltages too...) and only kill the power if that doesn't
> help and situation (with temperature/voltage) gets worse.

I would tend to agree with you here, Matti. Also from what I understand,
the wanted outcome is software handling a possibly temporary issue with
you charging caps, external IC initialization using (expectedly) much
more power than needed before stabilizing, and eventually handling other
"real" issues for which there is a solution that may not even include
disabling the regulator itself, but some other handling on the connected
device driver.

Though, Mark: for example, on qcom labibb, there's "PBS" that is killing
the regulators on short-circuit condition and as you see, handling that
is a little trickier compared to the over-current one, where there is no
such auto-magic-thing...
.... I wouldn't know if it'd be a good idea to have a system like qcom's
PBS everywhere.
For the sake of protecting HW "paranoidly" though.. maybe :))

> 
> What I don't like is the fact that HW keeps IRQ asserted instead of
> having a state machine which would only generate IRQ when condition
> changes + status register to read current condition.
> 

Unless I've misunderstood this, you're describing a *very* common
behavior across regulators and other kinds of devices, but that's
not a problem. IMO, it's a solution (to quirky MCUs/SoCs/CPUs/blah).

Of course reading a register means that you waste more time before
deciding to "press the red button", but even on a slow bus like I2C,
it's anyway not reaching the point where that wasted time is relevant.
At least, in many cases.

> I will see if I can cook-up something decent - but as I said, I would
> appreciate any/all testing if I get patch crafted :)

I develop this stuff in my spare time: I can't make big promises, but
I can tell you that I will try to test your proposal on qcom-labibb as
soon as I will be able to.

Yours,
--Angelo

> 
> Best Regards
> 	Matti
>