If the regulator is unused it will be disabled by the regulator_shutdown sysinit.
Tested on pinebook where the backlight is controlled by a fixed-regulator.
The regulator doesn't have a regulator-boot-on param (I'm gonna upstream this) and so we disable it at probe.
We later enable it but this cause the screen to go black.
Linux doesn't disable regulator at boot (at least for fixed-regulator) so better match this to have the same UX.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D17978
For most regulators, the regulator_stop() method can be transformed to
regulator disable. But, in some cases, we needs to maintain shared data
across multiple regulators (e.g. single GPIO pin which works as enable
for multiple regulates). In this case, the implementation of regulator
should perform his own enable counting therefore it is necessary to
distinguish between the regulator enable/disable method (which
increments/decrements enable counter for shared resource) and regulator
stop method (which don't affect it).
So:
- add regnode_stop() method to regulator framework and default it to
regnode_enable(..., false, ...)
- implement it in regulator_fixed with proper enable counting.
While I'm in, also fix handling of always_on property. If any of regulators
sharing same GPIO pin have it enabled, then none of them can disable regulator.
Tested by: kevans
MFC after: 3 weeks
These are represented as booleans on the kernel-side, but were being exposed
as int. This was causing some funky things to happen when read later with
sysctl(8), e.g. randomly reading super-high when the value was actually
'0'/false.
Reviewed by: manu
This was the wrong solution to the problem; regulator_shutdown invokes
regnode_stop. regulator_stop is not a refcounting method, but it invokes
regnode_enable, which is.
mmel@ has a proposed patch/solution to instead provide regnode_fixed_stop
behavior that properly takes shared GPIO pins into account.
regnode::enable_cnt is generally used to refcount regulator nodes. For
GPIOs, the refcount was done on the gpio_entry since more than one regulator
can share a GPIO.
GPIO regulators were not taking part in the node refcount, since they had
their own mechanism. This caused some fallout after manu started disabling
everybody's unused regulators in r331989.
Refcount it.
Glanced over by: manu
When disabling regulator when they are unused, check before is they are
enabled.
While here don't check the enable_cnt on the regulator entry as it is
checked by regnode_stop.
This solve the panic on any board using a fixed regulator that is driven
by a gpio when the regulator is unused.
Tested On: OrangePi One
Pointy Hat to: myself
Reported by: kevans, Milan Obuch (freebsd-arm@dino.sk)
Change OF_getencprop_alloc semantics to be combination of malloc and
OF_getencprop and return size of the property, not number of elements
allocated.
For the use cases where number of elements is preferred introduce
OF_getencprop_alloc_multi helper function that copies semantics
of OF_getencprop_alloc prior to this change.
This is to make OF_getencprop_alloc and OF_getencprop_alloc_multi
function signatures consistent with OF_getencprop_alloc and
OF_getencprop_alloc_multi.
Functionality-wise this patch is mostly rename of OF_getencprop_alloc
to OF_getencprop_alloc_multi except two calls in ofw_bus_setup_iinfo
where 1 was used as a block size.
OF_getprop_alloc takes element size argument and returns number of
elements in the property. There are valid use cases for such behavior
but mostly API consumers pass 1 as element size to get string
properties. What API users would expect from OF_getprop_alloc is to be
a combination of malloc + OF_getprop with the same semantic of return
value. This patch modifies API signature to match these expectations.
For the valid use cases with element size != 1 and to reduce
modification scope new OF_getprop_alloc_multi function has been
introduced that behaves the same way OF_getprop_alloc behaved prior to
this patch.
Reviewed by: ian, manu
Differential Revision: https://reviews.freebsd.org/D14850
bootloaders such as u-boot might enable regulators, or simply regulators could
be enabled by default by the PMIC, even if we don't have a driver for
the device or subsystem.
Disable unused regulators just before going to userland.
A tunable hw.regulator.disable_unused is added to not disable them in case
this causes problems on some board but the default behavior is to disable
everything unused.
I prefer to break thinks now and fix them rather than never switch to the
case were we disable regulators.
Tested on : Pine64-LTS (an idle board goes from ~0.33A to ~0.27A)
Tested on : BananaPi M2
Differential Revision: https://reviews.freebsd.org/D14781
For each regulators create an hw.regulator.<regname>. :
uvolt: Current value
always_on: 1 If the reg is always on
boot_on: 1 If the reg is set at boot time
enable_cnt: Number of consumer(s)
enable_delay: Delay before enabling the regulator
ramp_delay: The Ramp delay
max_uamp: The maximum value of the regulator in uAmps
min_uamp: The minimal value of the regulator in uAmps
max_uvolt: The maximum value of the regulator in uVolts
min_uvolt: The minimal value of the regulator in uVolts
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D14578
This reduces noise when kernel is compiled by newer GCC versions,
such as one used by external toolchain ports.
Reviewed by: kib, andrew(sys/arm and sys/arm64), emaste(partial), erj(partial)
Reviewed by: jhb (sys/dev/pci/* sys/kern/vfs_aio.c and sys/kern/kern_synch.c)
Differential Revision: https://reviews.freebsd.org/D10385
In some cases, the driver must handle given properties located in
specific OF subnode. Instead of creating duplicate set of function, add
'node' as argument to existing functions, defaulting it to device OF node.
MFC after: 3 weeks
support frameworks(i.e. clk/reset/phy/tsensors/fuses...).
The framework is still far from perfect and probably doesn't have stable
interface yet, but we want to start testing it on more real boards and
different architectures.