Re: [PATCH RFC 1/2] regulator: introduce regulator monitoring constraints

[Mark Brown]

On Thu, Apr 20, 2023 at 12:29:20PM +0200, Benjamin Bara wrote:

> Add constraints for regulator monitoring. These are useful when the
> state of the regulator might change during runtime, but the monitor
> state (in hardware) is not implicitly changed with the change of the
> regulator state or mode (in hardware).

> When used, the core takes care of handling the monitor state. This could
> ensure that a monitor does not stay active when its regulator is
> disabled.

Are these constraints (ie, board specific limits) or are these more just
properties of the regulator device?  It does feel useful to factor out
this stuff, but it's not clear to me that these are things that should
be configured on a per board basis. 

> + * @mon_disable_during_reg_set: Monitor should be disabled before and enabled after the regulators'
> + *                              value is changed
> + * @mon_disable_during_reg_off: Monitor should be disabled before a regulator disable and enabled
> + *                              after a regulator enable

> + * @mon_disable_pre_reg_idle: Monitor should be disabled before a switch to MODE_IDLE
> + * @mon_disable_pre_reg_standby: Monitor should be disabled before a switch to MODE_STANDBY
> + * @mon_enable_post_reg_normal: Monitor should be enabled after a switch to MODE_NORMAL
> + * @mon_enable_post_reg_fast: Monitor should be enabled after a switch to MODE_FAST

These all sound like things where the regulator device is simply not
going to support having monitoring enabled when doing the relevant
actions no matter what situation we're in.  If that's the case we should
just have the regulator driver set things up.

For the modes might it be clearer to mark a set of modes as not
supporting monitoring?  I think that's the intended effect here.

Attachment: signature.asc
Description: PGP signature