On Mon, 2008-03-10 at 18:00 -0800, David Brownell wrote:
I think we probably have some confusion over the nomenclature here (as
there are several 'levels' of constraint). I'll detail this in the docs
though.
I think you are meaning the board (or power domain) constraint here:-
The regulator driver currently enforces the chip (or regulator)
constraints, whilst the power domain (board) constraints are defined in
board.c.
e.g.
struct regulation_constraints led = {
.min_uA = 0,
.max_uA = 27898,
.valid_ops_mask = REGULATOR_CHANGE_CURRENT,
.valid_modes_mask = REGULATOR_MODE_NORMAL,
};
struct regulation_constraints cpufreq = {
.min_uV = mV_to_uV(1300),
.max_uV = mV_to_uV(1600),
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE | REGULATOR_CHANGE_MODE,
.valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_FAST,
};
It designed to work as follows:-
1. Consumer: set voltage 1.8V
2. reg core: if 1.8V is not within board (power domain) constraint then
return err.
3. regulator (chip) driver: check that 1.8V is ok then write to chip to
change voltage.
A board designer must make sure that the power domain constraints are
within the regulator (chip) constraints. He must also make sure that all
consumers on a power domain can all operate similtaiously at the same
voltage and that they are not damaged by other domain consumers
operating at different voltages.
Basically there are two types of consumers.
1. Consumers that don't care about their supply voltage/current. They
use the voltage specified by the system designer and don't care about
it's value. They only need to enable()/disable()
2. Consumers that do care about their voltage/current. This group of
consumers do care about voltage and current. Typical users are
Backlight, CPUfreq, LED's, MMC, vibrator, USB.....
The first type can usually share a supply regulator whilst the latter
group have a 1:1 consumer to regulator mapping.
The system designer ensures that all type 1 consumers exist on domains
with compatible power requirements. Type 1 consumers don't care about
voltage or current constraints.
Type 2 consumers do care about power domain constraints.
This also leads to 3 different types of power domain :-
1. Fixed Voltage.
2. Variable Voltage.
3. Variable Current limit.
We have the physical constraints of the regulators (chip) and the
physical constraints of the power domain. The power domain example near
the top hopefully answers this.
Agreed, they do.
Imho, the regulator driver should not no anything about the board. It's
up to the board init code to configure things like this.
We do this atm for a WM8350 resistor config in platform code and pass
onto the pmic driver.
This is probably a bad example as the voltage delta is quite large and
probably unrealistic. I was thinking of smaller deltas in the range of a
few percent. The big numbers just make it easier to read. I'm beginning
to consider removing this feature.
We have a notifier block for notifying changes atm but it doesn't notify
other domain consumers of a pending domain voltage change yet.
Imho no, as the regulator internals will probably still be clocking and
burning power when set to 0V. I think we need the enable() and disable()
calls to do make this cleaner.
Yes, this is fine.
It should fail. However, it might be worth adding something like :-
regulator_set_voltage(client, min, max);
regulator_set_current(client, min, max);
I think it's probably best that I write some docs describing the
architecture and usage model before any more patches. Hopefully, this
will clear up the ambiguities around constraints and nomenclature. I'll
also factor in the recent comments in this email chain.
Liam
--
