On Thu, Nov 19, 2020 at 05:22:43PM +0300, Dmitry Osipenko wrote:
16.11.2020 16:33, Mark Brown пишет:
quoted
No, you are failing to understand the purpose of this code. To
reiterate unless the device supports operating with the supply
physically absent then the driver should not be attempting to use
regulator_get_optional(). That exists specifically for the case where
The original intention of regulator_get_optional() is clear to me, but
nothing really stops drivers from slightly re-purposing this API, IMO.
Drivers should be free to assume that if regulator isn't defined by
firmware, then it's physically absent if this doesn't break anything. Of
course in some cases it's unsafe to make such assumptions. I think it's
a bit unpractical to artificially limit API usage without a good reason,
i.e. if nothing breaks underneath of a driver.
If the supply can be physically absent without breaking anything then
this is the intended use case for optional regulators. This is a *very*
uncommon.
quoted
Regulators that are present but not described by the firmware are a
clearly different case to regulators that are not physically there,
hardware with actually optional regulators will generally require some
configuration for this case.
I have good news. After spending some more time on trying out different
things, I found that my previous assumption about the fixed-regulator
was wrong, it actually accepts voltage changes, i.e. regulator consumer
doesn't get a error on a voltage-change. This is exactly what is needed
for the OPP core to work properly.
To be clear when you set a voltage range you will get the minimum
voltage that can be supported within that range on the system given all
the other constraints the system has. For fixed voltage regulators or
regulators constraints to not change voltage this means that if whatever
voltage they are fixed at is in the range requested then the API will
report success.