[lkml]   [2017]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] regulator: core: Add coupled regulators mechanism
On Tue, Sep 19, 2017 at 04:35:54PM +0200, Maciej Purski wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.

> On 09/19/2017 03:09 PM, Mark Brown wrote:

> and from my new function regulator_set_coupled_voltage(). I added this in order to avoid
> code duplication. I agree that the name might not be adequate. What name would you find more suitable?

I think if the single regulator case isn't just a special case of the
multi regulator case then we're doing this wrong and there will be
maintainability problems so I'm not sure if this split makes sense at

> > There's no locking here, and we appear to take no action when these
> > counts change - do we need to bother with this at all?

> Variable enable_count is used for checking if both regulators are enabled and there's a need for
> using the coupling mechanism. It is checked in regulator_set_coupled_voltage_unlocked(), where the
> mutex is already locked. I think that locking it here would be useful. Thanks.

So what happens if one regulator is enabled after the other and the
constraints become unsatisified?

> > > + /* Get voltages desired by all consumers of the coupled regulator */
> > > + for (i = 0; i < 2; i++) {

> > It appears we can't couple more than two regulators?

> We can couple just two regulators. We have never found any case for coupling
> more than two regulators. Limiting the mechanism to just two regulators simplifies
> algorithm a little bit. Would you prefer it working for more than two
> regulators also even if there isn't any use case?

It seems cleaner.
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2017-09-19 16:48    [W:0.044 / U:1.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site