Linux processes these clocks in reverse order and some DT relies
on this fact. For example, the frequency setting for a given PLL
is the last in the list, preceded by the frequency setting of its
following divider or so...
MFC after: 1 week
On some boards there is a lot of of syscon node that are unused as
more specific drivers is probed before, no need to flood the console
for the mostly-unused generic ones.
MFC after: 1 week
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT
Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718
Some consumer cannot know the voltage of the regulator without it.
While here, refuse to attach is min_voltage != max_voltage, it
shouldn't happens anyway.
Reviewed by: mmel
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D23003
Highlights:
- Exit early if we're not disabling unused regulators; there's no need to
take the regulator topology lock and re-evaluate this every iteration, as
it's not going to change.
- Don't emit a notice that we're shutting down a regulator if it's not
enabled, to reduce noise.
- Mention the outcome of the shutdown, to aide debugging and easily let
developer/user collect list of regulators we actually shutdown to
determine problematic one.
Reviewed by: manu
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D22213
This method is supposed to write the voltage into uvolt
and return an errno compatible value.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D23006
This kind of clock nodes represent temporary placeholder for clocks
defined later in boot process. Also, these are necessary to break
circular dependencies occasionally occurring in complex clock graphs.
MFC after: 3 weeks
This function will call the regnode_check_voltage method for a given regulator
and check if the desired voltage in reachable by it.
Also adds a default method that check the std_param and which should be enough
for most regulators and add it as the method for axp* rk805 and fixed regulators.
Reviewed by: mmel
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D22260
This method check that boot_on or always_on is set to 1 and if it
is it will try to enable the regulator.
The binding docs aren't clear on what to do but Linux enable the regulator
if any of those properties is set so we want to do the same.
The function first check the status to see if the regulator is
already enabled it then get the voltage to check if it is in a acceptable
range and then enables it.
This will be either called from the regnode_init method (if it's needed by the platform)
or by a SYSINIT at SI_SUB_LAST
Reviewed by: mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22106
If simple multifuction device also provides syscon interface, its
childern should be able to consume it. Due to this:
- declare coresponding method in syscon interface
- implement it in simple multifunction device driver
MFC after: 1 week
We used the aw_clk_nm clock for clock with only one divider factor
and used a fake multiplier factor. This cannot work properly as we
end up writing the "fake" factor to the register (and so always set
the LSB to 1).
Create a new clock for those.
The reason for not using the clk_div clock is because those clocks are
a bit special. Since they are (almost) all related to video we also need
to set the parent clock (the main PLL) to a frequency that they can support.
As the main PLL have some minimal frequency that they can support we need to
be able to set the main PLL to a multiple of the desired frequency.
Let say you want to have a 71Mhz pixel clock (typical for a 1280x800 display)
and the main PLL cannot go under 192Mhz, you need to set it to 3 times the
desired frequency and set the divider to 3 on the hdmi clock.
So this also introduce the CLK_SET_ROUND_MULTIPLE flag that allow for this kind
of scenario.
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
pollution substantially.
EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).
As a side effect of reduced header pollution, many .c files and headers no
longer contain needed definitions. The remainder of the patch addresses
adding appropriate includes to fix those files.
LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
sys/mutex.h since r326106 (but silently protected by header pollution prior
to this change).
No functional change (intended). Of course, any out of tree modules that
relied on header pollution for sys/eventhandler.h, sys/lock.h, or
sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped.
ofw_bus_parse_xref_list_get_length doesn't returns the number of elements, fix this.
While here when setting the clock to the assigned freqeuncy, allow the clock
driver to round down or up the frequency as sometimes the exact frequency cannot
be obtain.
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
We didn't allowed a divider register value of 0 which can exists and
also didn't wrote the value but the divider, which result of a wrong
frequency to be selected
The nvmem interface helps provider of nvmem data to expose themselves to consumer.
NVMEM is generally present on some embedded board in a form of eeprom or fuses.
The nvmem api are helpers for consumer to read/write the cell data from a provider.
Differential Revision: https://reviews.freebsd.org/D16419
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
The properties 'assigned-clocks', 'assigned-clock-parents' and
'assigned-clock-rates' all work together.
'assigned-clocks' holds the list of clock for which we need to either
assign a new parent or a new frequency.
The old code just supported assigning a new parents, add support for
assigning a new frequency too.
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
Similarly as other extres pseudo-drivers, implement phy by using kobj model.
This detaches it from provider device, so single device driver can export
multiple different phys. Additionally, this allows phy to be subclassed to
more specialized drivers, like is USB OTG phy, or PCIe phy with hot-plug
capability.
Tested by: manu (previous version, on Allwinner board)
MFC after: 1 month
During set_freq a clknode might have reparent (using a better parent that
have a higher frequency for example), before refreshing the cache, re-get
the parent frequency.
Reviewed by: mmel
Attaching syscon_generic earlier than BUS_PASS_DEFAULT makes it more
difficult for specific syscon drivers to attach to the syscon node and to
get ordering right. Further discussion yielded the following set of
decisions:
- Move syscon_generic to BUS_PASS_DEFAULT
- If a platform needs a syscon with different attach order or probe
behavior, it should subclass syscon_generic and match on the SoC specific
compat string
- When we come across a need for a syscon that attaches earlier but only
specifies compatible = "syscon", we should create a syscon_exclusive driver
that provides generic access but probes earlier and only matches if "syscon"
is the only compatible. Such fdt nodes do exist in the wild right now, but
we don't really use them at the moment.
Additionally:
- Any syscon provider that has needs any more complex than a spinlock solely
for syscon access and a single memory resource should subclass syscon
directly rather than attempting to subclass syscon_generic or add complexity
to it. syscon_generic's attach/detach methods may be made public should the
need arise to subclass it with additional attach/detach behavior.
We introduce aw_syscon(4) that just subclasses syscon_generic but probes
earlier to meet our requirements for if_awg and implements #2 above for this
specific situation. It currently only matches a64/a83t/h3 since these are
the only platforms that really need it at the time being.
Discussed with: ian
Reviewed by: manu, andrew, bcr (manpages, content unchanged since review)
Differential Revision: https://reviews.freebsd.org/D13793
ian@ pointed out that BUS_PASS_DEFAULT + $anything is bogus, given that
BUS_PASS_DEFAULT is defined as __INT_MAX. Instead, we take a page out of
imx6_usbphy's book and use BUS_PASS_DEFAULT - 1000 to achieve the desired
effect of syscon_generic attaching before if_awg and other potential
consumers, but late enough that more specialized implementations should have
no problem attaching instead.
Reported by: ian
It still needs to be before if_awg at least in order to be available for
other operations, but it should not be attaching before interrupt
controllers at the very least.
This should make errors involving syscon register space colliding with other
devices a little more innocent, but these conflicts should really be tracked
down and resolved. One such conflict is with the Raspberry Pi 3 local
interrupt controller, noticed by tuexen@
Reported by: tuexen
r327106 introduced kobj to syscon so it can be subclassed and fit in with
the rest of the syscon framework. The diff for syscon.c was misapplied in a
clean tree prior to commit, so bring it back to what was included in the
review and tested. The entire file has basically been rewritten from what
was present prior to the kobj work.
Pointy hat to: me
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
This should help reduce confusion between syscon/syscons a little bit.
syscon is a resource generally modeled by FDT platforms, and not to be
confused with syscons.
