Hello 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 :]
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.
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.
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 :)
Best Regards
Matti