This variable was flagged as a set but unused warning as its value was
read from a register and then modified to set a bit
(TI_MBOX_SYSCONFIG_SOFTRST). After the variable is modified, the code
then loops waiting for the SOFTRST bit to go clear in the
TI_MBOX_SYSCONFIG register. Presumably merely reading from the
register does not request a reset as other places in the driver read
this register, so most likely the updated value of sysconfig setting
the reset bit is supposed to be written to the register to request a
reset before the polling loop that waits for the reset to finish.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D34856
gpio_pin are calculated as [GPIO_BANK]*32 + GPIO_PIN.
gpio_pin are wrong for these pins.
As a consequence wrong pins are acquired and used.
Approved by: manu (mentor)
Reported by: Martin Zakardissnehf
(martin.zakardissnehf@se.abb.com)
Differential revision: https://reviews.freebsd.org/D31164
Add support for invert the polarity of the PWM signal.
Cleanup and add comments in the initialization code.
Add and fix register defines.
Approved by: manu (mentor)
Differential revision: https://reviews.freebsd.org/D29547
To minimize the maintenance time of this driver when new features
are added the legacy sysctl interface has to go.
Approved by: manu (mentor)
Reviewed by: Dr. Rolf Jansen (freebsd-rj_obsigna.com)
Differential revision: https://reviews.freebsd.org/D29546
This reverts commit aa37baf3d7.
The reverted commit was motivated by a problem observed on stable/12,
but it turns out that a better solution was committed in r348309 but not
MFCed. So, revert this change since it is unnecessary and not really
correct: it assumes that the order in which module metadata records is
defined determines their order in the output linker set. While this
seems to hold in my testing, it is not guaranteed.
Reported by: cem
Discussed with: imp
MFC after: 3 days
PNP info definitions currently have an unfortunate requirement in that
they must follow the associated module definition in the module metadata
linker set. Otherwise devmatch can segfault while processing the linker
hints file since kldxref maintains the order in the linker set.
A number of drivers violate this requirement. In some cases this can
cause devmatch(8) to segfault when processing the linker hints file.
Work around the problem for now simply by adjusting the drivers.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D28260
devctl_notify_f isn't needed, so retire it. The flags argument is now
unused, so rather than keep it around, retire it. Convert all old
users of it to devctl_notify(). This path no longer sleeps, so is safe
to call from any context. Since it doesn't sleep, it doesn't need to
know if it is OK to sleep or not.
Reviewed by: markj@
Differential Revision: https://reviews.freebsd.org/D26140
Re-implement clocks for these SoC by using now standard extres/clk framework.
This is necessary for future expansion of these. The new implementation
is (due to the size of the patch) only the initial (minimum) version.
It will be updated/expanded with a subsequent set of particular patches.
This patch is also not tested on OMAP4 based boards (BeagleBone),
so all possible issues should be (and will be) fixed by ASAP once
identified.
Submited by: Oskar Holmlund (oskar.holmlund@ohdata.se)
Differential Revision: https://reviews.freebsd.org/D25118
Honor ti,pmic-shutdown-controller option in DTS
Tested on stable r359316 @ Sleep mode on custom hw, Power off on BBB and PB
OFF bit [1] in status register control the pmic behaviour when PWR_EN pin
is pulled low.
On most AM335x hardware [beaglebone *] the desired behaviour are in fact
power off due to some hardware designs - read more in the comments around
pmic in sys/gnu/dts/arm/am335x-bone-common.dtsi
This patch let the device-tree decide with ti,pmic-shutdown-controller[2]
the state of off bit in status register.
[1] 8.6.12 table 12 http://www.ti.com/lit/ds/symlink/tps65217.pdf
[2] Documentation/devicetree/bindings/regulator/tps65217.txt
PR: 245159
Submitted by: Oskar Holmlund <oskar.holmlund@ohdata.se>
MFC after: 2 weeks
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
As far as I can tell, these are an artifact of times when linker sets
couldn't be empty, otherwise the kernel build would fail due to unresolved
symbols. hselasky fixed this in r268138, and I've audited the kbd portions
to make sure nothing would blow up due to the empty linker set and
successfully compiled+ran a kernel with no keyboard support at all.
Kill them off now since they're no longer required.
MFC after: 1 week
Delay the attachment of children, when requested, until after interrutps are
running. This is often needed to allow children to run transactions on i2c or
spi busses. It's a common enough idiom that it will be useful to have its own
wrapper.
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D21465
in this driver indicate that the SD_CAPA register is write-once and after
being set one time the values in it cannot be changed. That turns out not
to be the case -- the values written to it survive a reset, but they can
be rewritten/changed at any time.
should be) correct, they lead to the eMMC on a Beaglebone failing to work
in some situations.
The TI sdhci hardware is kind of strange. The first device inherently
supports 1.8v and 3.3v and the abililty to switch between them, and the
other two devices must be set to 1.8v in the sdhci power control register to
operate correctly, but doing so actually makes them run at 3.3v (unless an
external level-shifter is present in the signal path). Even the 1.8v on the
first device may actually be 3.3v (or any other value), depending on what
voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip.
Another strange quirk is that the convention for am335x sdhci drivers in
linux and uboot and the am335x boot ROM seems to be to set the voltage in
the sdhci capabilities register to 3.0v even though the actual voltage is
3.3v. Why this is done is a complete mystery to me, but it seems to be
required for correct operation.
If we had complete modern support for the am335x chip we could get the
actual voltages from the FDT data and the regulator framework. But our
am335x code currently doesn't have any regulator framework support.
Reverting to the prior code will get the popular Beaglebone boards working
again.
This is part of the fix for PR 241301, but also requires r353651 for a
complete fix.
PR: 241301
Discussed with: manu
that makes the upstream FDT data work right, so we don't need to see a
couple dozen instances of it spam the dmesg at boot time unless it's a
verbose boot.
ioctl(2) handling. This allows doing the pps_event() work in the polling
routine, instead of using a taskqueue task to do that work.
Also, add PNPINFO, and switch to using make_dev_s() to create the cdev.
Using a spin mutex and calling pps_event() from the polling function works
around the situation which requires more than 2 sets of timecounter
timehands in a single-core system to get reliable PPS capture. That problem
would happen when a single-core system is idle in cpu_idle() then gets woken
up with an event timer event which was scheduled to handle a hardclock tick.
That processing path would end up calling tc_windup 3 or 4 times between
when the tc polling function was called and when the taskqueue task would
eventually run, and with only two sets of timehands, the th_generation count
would always be too old to allow the captured PPS data to be used.
ti,dual-volt property say that the eMMC support 1.8V and 3.3V not 3.0V
Use the correct caps for the mmc stack.
Note that the MMCHS_SD_CAPA register can only be written once after bootup
so if one is using a u-boot compiled with eMMC support (this is the default)
this code is a no-op but just in case someone have u-boot compiled without
eMMC support this make eMMC works when the kernel is booted.
MFC after: 1 week
status register clears pending interrupts. By moving that code out of the
interrupt handler into a taskqueue task, I effectively created an interrupt
storm by returning from the handler with the interrupt source still active.
We'll have to find a different solution for this driver's need to sleep
in an ithread context.
Long ago this was needed, but now low-level i2c controller drivers cleverly
defer attachment of the bus until interrupts are enabled (if they require
interrupts to function), so that every i2c slave device doesn't have to.
Since DTS from >= Linux 5.0 the slave address are relative to the parent
node address and aren't the full ones.
Check both so the cpsw driver can find the phy id.
r350229 changed the code to lookup the ti,hwmods property in the parent
as it's now like that in the DTS from >= Linux 5.0, allow the property
to be also in the node itself so we can boot with an older DTB.
Reported by: "Dr. Rolf Jansen" <rj@obsigna.com>
pwm(9), but also maintains the historical sysctl config interface for
compatiblity with existing apps. The two config systems are not compatible
with each other; if you use both interfaces to change configurations you're
likely to end up with incorrect output or none at all.
upcoming functional changes.
Add an ofw_compat_data table for probing compat strings, and use it to add
PNP data. Remove some stray semicolons at the end of macro definitions,
and add a PWM_LOCK_ASSERT macro to round out the usual suite. Move the
device_t and driver_methods structs to the end of the file. Tweak comments.
pollution that was cleaned up recently, and this file got missed in the
cleanup because it's not attached to the build unless you specifically
request this device in a custom kernel config.
This was enumerated with exhaustive search for sys/eventhandler.h includes,
cross-referenced against EVENTHANDLER_* usage with the comm(1) utility. Manual
checking was performed to avoid redundant includes in some drivers where a
common os_bsd.h (for example) included sys/eventhandler.h indirectly, but it is
possible some of these are redundant with driver-specific headers in ways I
didn't notice.
(These CUs did not show up as missing eventhandler.h in tinderbox.)
X-MFC-With: r347984
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.
