As I agreed earlier, its true about requirement. It is also true that the clock API can suffice.
But what is essential here is: we are talking about regulators here.
Why would we need to model a seemingly similar regulator as a clock?
Again here, more similarities for a power domain with a regulator.
1. Both power domains and a regulator can be enabled/disabled.
2. Both power domains and a regulator can be controlled to a specific voltage.
3. Every peripheral is dependent on both power domains and a regulator to be essentially
on. Turning off the clocks will disable the peripheral, but it is not the same as turning off
the peripheral. And here is where the biggest difference from the clock API. You can disable
the peripheral clock with the clk_disable, but turning it off will be encroachment there. Whilst
a regulator_disable is the most logical fit here.
4. Both power domains and a regulator can be enforced upon constraints from their clients.
*What* power domains and regulators differ about is:
1.a the nature of constraints is a bit different. On SoC regulators aka power domains have usually
a fixed set of clients which don't vary, but off SoC regulators can have varying clients.
2.a On SoC regulators aka power domains allow you controlling operational states like
On/Off/Retention/Idle etc, whilst conventional regulators are more happy judging their current loads.
However, this still doesn't stop anyone from actually adding operational states to regulators.
I agree with your reservations about pains trying to co-relate exactly a power domain and a regulator.
If you agree, from the top, reaching out to bottom, there are only subtle differences and these
differences (1.a/2.a) can also be incorporated into conventional regulators which can be gradually
diminishing, whereas the similarities, (1,2,3,4) can only possible increase!
Thanks,
Sundar
--
