Messages in this thread | | | Subject | Re: short-circuit and over-current IRQs | From | AngeloGioacchino Del Regno <> | Date | Wed, 27 Jan 2021 15:34:46 +0100 |
| |
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 >
| |