From: Mark Brown <firstname.lastname@example.org> To: AngeloGioacchino Del Regno <email@example.com> Cc: firstname.lastname@example.org, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: short-circuit and over-current IRQs Date: Wed, 27 Jan 2021 16:32:18 +0000 [thread overview] Message-ID: <20210127163218.GD4387@sirena.org.uk> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 1898 bytes --] On Wed, Jan 27, 2021 at 03:34:46PM +0100, AngeloGioacchino Del Regno wrote: > Il 27/01/21 13:56, Matti Vaittinen ha scritto: > > 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 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. Note that the events the API currently has are expected to be for the actual error conditions, not for the warning ones - indicating that the voltage is out of regulation for example. If you're supporting warning notifications as well you'll want to add more events (or possibly another flag to munge in with the existing events to indicate that it's a warning rather than an error). > 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 :)) Well, if these things are kicking in the hardware is in serious trouble anyway so it's unclear what the system would be likely to do in software, and also unclear how safe it is to rely on software to be able to take that action given that it let things get into such a bad state in the first place. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-01-27 16:34 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-27 12:01 Vaittinen, Matti 2021-01-27 12:27 ` Mark Brown 2021-01-27 12:56 ` Matti Vaittinen 2021-01-27 14:34 ` AngeloGioacchino Del Regno 2021-01-27 14:42 ` Vaittinen, Matti 2021-01-27 16:32 ` Mark Brown [this message] 2021-01-28 9:23 ` Vaittinen, Matti 2021-01-28 12:10 ` Mark Brown 2021-01-28 12:49 ` Vaittinen, Matti [not found] ` <firstname.lastname@example.org> 2021-01-30 15:43 ` AngeloGioacchino Del Regno 2021-02-01 7:14 ` Matti Vaittinen 2021-02-01 13:17 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210127163218.GD4387@sirena.org.uk \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: short-circuit and over-current IRQs' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).