voltage and current regulator framework: specifying negative voltages

voltage and current regulator framework: specifying negative voltages

[Hennerich, Michael]

Hi Mark and Liam,

I wonder why the voltage and current regulator framework doesn't support negative voltages.
We like to use the framework to specify bipolar reference voltages used with converters.
However in various places negative voltages are treated as error codes, thus causing the regulator to exit on probe.

As a workaround someone could say we specify positive and negative supply by label with absolute values and add the negative sign in the consumer driver.
However that doesn't work well, since the bipolar 'negative' supply may also occasionally be positive.

Thoughts?

Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif

Re: voltage and current regulator framework: specifying negative voltages

[Mark Brown]

On Tue, Apr 12, 2011 at 12:08:22PM +0100, Hennerich, Michael wrote:

Please fix your mail client to word wrap at less than 80 columns - see
Documentation/email-clients.txt for suggestions.  I've reflowed your
text for legibility.

> I wonder why the voltage and current regulator framework doesn't
> support negative voltages.  We like to use the framework to specify
> bipolar reference voltages used with converters.  However in various
> places negative voltages are treated as error codes, thus causing the
> regulator to exit on probe.

Basically just a lack of demand - there are few negative supplies in
the mobile systems that were looked at, and most of those are like the
charge pumps found in audio CODECs and not really visible as regulators
that could be used with other devices.

> As a workaround someone could say we specify positive and negative
> supply by label with absolute values and add the negative sign in the
> consumer driver.  However that doesn't work well, since the bipolar
> 'negative' supply may also occasionally be positive.

That'd probably work.  Or update the API to allow negative voltages to
be returned more easily; off the top of my head the only real issue is
get_voltage() and so on.  It'd not be great for usability, though.

Re: voltage and current regulator framework: specifying negative voltages

[Michael Hennerich]

On 04/12/2011 05:21 PM, Mark Brown wrote:
> On Tue, Apr 12, 2011 at 12:08:22PM +0100, Hennerich, Michael wrote:
>
> Please fix your mail client to word wrap at less than 80 columns - see
> Documentation/email-clients.txt for suggestions.  I've reflowed your
> text for legibility.
>
>   
>> I wonder why the voltage and current regulator framework doesn't
>> support negative voltages.  We like to use the framework to specify
>> bipolar reference voltages used with converters.  However in various
>> places negative voltages are treated as error codes, thus causing the
>> regulator to exit on probe.
>>     
> Basically just a lack of demand - there are few negative supplies in
> the mobile systems that were looked at, and most of those are like the
> charge pumps found in audio CODECs and not really visible as regulators
> that could be used with other devices.
>   

Hi Mark,

Contrast control for LC Displays typically use negative voltages, too
I agree that demand for this on typical mobile devices is low, however
we like
to use the regulator framework in the IIO subsystem where negative voltages
are quite common.
>   
>> As a workaround someone could say we specify positive and negative
>> supply by label with absolute values and add the negative sign in the
>> consumer driver.  However that doesn't work well, since the bipolar
>> 'negative' supply may also occasionally be positive.
>>     
> That'd probably work.  Or update the API to allow negative voltages to
> be returned more easily; off the top of my head the only real issue is
> get_voltage() and so on.  It'd not be great for usability, though.
>   
Updating the core to allow negative and zero voltages, is not  straight
forward.
There are more issues with constrain checking and I currently can't
oversee all side
effects. I think we need to introduce a new constrains flag
(maybe add to valid_modes_mask?), indicating a bipolar regulator.
This flag is then used to keep the current implementation untouched for
unipolar positive
regulators.

Thoughts?
 

-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

Re: voltage and current regulator framework: specifying negative voltages

[Liam Girdwood]

On Wed, 2011-04-13 at 14:22 +0200, Michael Hennerich wrote:
> On 04/12/2011 05:21 PM, Mark Brown wrote:
> > On Tue, Apr 12, 2011 at 12:08:22PM +0100, Hennerich, Michael wrote:
> >
> > Please fix your mail client to word wrap at less than 80 columns - see
> > Documentation/email-clients.txt for suggestions.  I've reflowed your
> > text for legibility.
> >
> >   
> >> I wonder why the voltage and current regulator framework doesn't
> >> support negative voltages.  We like to use the framework to specify
> >> bipolar reference voltages used with converters.  However in various
> >> places negative voltages are treated as error codes, thus causing the
> >> regulator to exit on probe.
> >>     
> > Basically just a lack of demand - there are few negative supplies in
> > the mobile systems that were looked at, and most of those are like the
> > charge pumps found in audio CODECs and not really visible as regulators
> > that could be used with other devices.
> >   
> 
> Hi Mark,
> 
> Contrast control for LC Displays typically use negative voltages, too
> I agree that demand for this on typical mobile devices is low, however
> we like
> to use the regulator framework in the IIO subsystem where negative voltages
> are quite common.
> >   
> >> As a workaround someone could say we specify positive and negative
> >> supply by label with absolute values and add the negative sign in the
> >> consumer driver.  However that doesn't work well, since the bipolar
> >> 'negative' supply may also occasionally be positive.
> >>     
> > That'd probably work.  Or update the API to allow negative voltages to
> > be returned more easily; off the top of my head the only real issue is
> > get_voltage() and so on.  It'd not be great for usability, though.
> >   
> Updating the core to allow negative and zero voltages, is not  straight
> forward.
> There are more issues with constrain checking and I currently can't
> oversee all side

The voltage constraints are just treated as numbers so negative
constraints for bipolar regulators should be fine here. I don't
anticipate lots of rework here. 

There is also some core logic that selects the lowest voltage within a
range of valid voltages (to save power) when consumers set a voltage.
This would need changed a little to support negative voltages since the
lowest voltage will be the _highest_ negative voltage. 

> effects. I think we need to introduce a new constrains flag
> (maybe add to valid_modes_mask?), indicating a bipolar regulator.
> This flag is then used to keep the current implementation untouched for
> unipolar positive
> regulators.
> 
> Thoughts?
>  

My preference is to keep it simple and the API consistent with unipolar
regulators.

One of the problem areas will be regulator_get_voltage() since it
returns negative errors. It may be desirable to deprecate this API call
in favour of a new call that we pass in an int for the voltage (e.g.
get_voltage(reg, &voltage)).

Lets also hear what Mark's thoughts too.

Regards

Liam

Re: voltage and current regulator framework: specifying negative voltages

[Mark Brown]

On Wed, Apr 13, 2011 at 02:43:21PM +0100, Liam Girdwood wrote:
> On Wed, 2011-04-13 at 14:22 +0200, Michael Hennerich wrote:

> > Contrast control for LC Displays typically use negative voltages, too
> > I agree that demand for this on typical mobile devices is low, however
> > we like

Yeah, that and the eInk displays are the only application I'm aware of.

> > to use the regulator framework in the IIO subsystem where negative voltages
> > are quite common.

Are these regulators software controlled?

> > Updating the core to allow negative and zero voltages, is not  straight
> > forward.
> > There are more issues with constrain checking and I currently can't
> > oversee all side

What are the issues that you see?

> > effects. I think we need to introduce a new constrains flag
> > (maybe add to valid_modes_mask?), indicating a bipolar regulator.
> > This flag is then used to keep the current implementation untouched for
> > unipolar positive
> > regulators.

> My preference is to keep it simple and the API consistent with unipolar
> regulators.

I agree, though if people do ever use the same regulators for both
polarities (with the polarity determined by supply) then we'll need a
way of dealing with this in the constraints as the regulators might not
know they're running negative voltages with respect to the system.

> One of the problem areas will be regulator_get_voltage() since it
> returns negative errors. It may be desirable to deprecate this API call
> in favour of a new call that we pass in an int for the voltage (e.g.
> get_voltage(reg, &voltage)).

I'm not sure deprecating it is ideal - it's quite a convenient API.  We
could just implement a new API and leave that one as an adaption layer.
Transition issues would mean that we'd want to do that for at least one
kernel release anyway.

Re: voltage and current regulator framework: specifying negative voltages

[Michael Hennerich]

On 04/13/2011 07:24 PM, Mark Brown wrote:
> On Wed, Apr 13, 2011 at 02:43:21PM +0100, Liam Girdwood wrote:
>   
>> On Wed, 2011-04-13 at 14:22 +0200, Michael Hennerich wrote:
>>     
>   
>>> Contrast control for LC Displays typically use negative voltages, too
>>> I agree that demand for this on typical mobile devices is low, however
>>> we like
>>>       
> Yeah, that and the eInk displays are the only application I'm aware of.
>
>   
>>> to use the regulator framework in the IIO subsystem where negative voltages
>>> are quite common.
>>>       
> Are these regulators software controlled?
>   
The cases I'm dealing with are fix voltage regulators with only
enable/disable controls.
 
>   
>>> Updating the core to allow negative and zero voltages, is not  straight
>>> forward.
>>> There are more issues with constrain checking and I currently can't
>>> oversee all side
>>>       
> What are the issues that you see?
>   
In case the output voltage can be negative, the input voltage may be
negative as well.
In functions drms_uA_update() and regulator_set_optimum_mode(), the
input supply voltage
is checked for being > 0, if that fails it uses the constrains->input_uV
instead...

BTW: Function drms_uA_update() looks suspicious.

    /* get input voltage */
    input_uV = 0;
    if (rdev->supply)
        input_uV = _regulator_get_voltage(rdev);

it checks for rdev->supply but later uses rdev, which will ultimately
mean input_uV == output_uV.
 
>   
>>> effects. I think we need to introduce a new constrains flag
>>> (maybe add to valid_modes_mask?), indicating a bipolar regulator.
>>> This flag is then used to keep the current implementation untouched for
>>> unipolar positive
>>> regulators.
>>>       
>   
>> My preference is to keep it simple and the API consistent with unipolar
>> regulators.
>>     
> I agree, though if people do ever use the same regulators for both
> polarities (with the polarity determined by supply) then we'll need a
> way of dealing with this in the constraints as the regulators might not
> know they're running negative voltages with respect to the system.
>
>   
>> One of the problem areas will be regulator_get_voltage() since it
>> returns negative errors. It may be desirable to deprecate this API call
>> in favour of a new call that we pass in an int for the voltage (e.g.
>> get_voltage(reg, &voltage)).
>>     
> I'm not sure deprecating it is ideal - it's quite a convenient API.  We
> could just implement a new API and leave that one as an adaption layer.
> Transition issues would mean that we'd want to do that for at least one
> kernel release anyway.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif

Re: voltage and current regulator framework: specifying negative voltages

[Mark Brown]

On Thu, Apr 14, 2011 at 12:44:43PM +0200, Michael Hennerich wrote:
> On 04/13/2011 07:24 PM, Mark Brown wrote:

Please cut irrelevant context from your replies.

> >>> Updating the core to allow negative and zero voltages, is not  straight
> >>> forward.
> >>> There are more issues with constrain checking and I currently can't
> >>> oversee all side

> > What are the issues that you see?

> In case the output voltage can be negative, the input voltage may be
> negative as well.
> In functions drms_uA_update() and regulator_set_optimum_mode(), the
> input supply voltage
> is checked for being > 0, if that fails it uses the constrains->input_uV
> instead...

None of this seems particularly complicated to deal with, it's not a
massive change in the architecture of the code or anything - it's all
just refactoring interfaces and implementations a bit.

> BTW: Function drms_uA_update() looks suspicious.

>     /* get input voltage */
>     input_uV = 0;
>     if (rdev->supply)
>         input_uV = _regulator_get_voltage(rdev);

> it checks for rdev->supply but later uses rdev, which will ultimately
> mean input_uV == output_uV.

There's very few users of supplies in mainline and no users at all of
the optimal mode stuff.