given in random(4).
This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.
Ensure that the pseudo-unit-test still does something useful, now also
with the "other" algorithm instead of Yarrow.
PR: 230870
Reviewed by: cem
Approved by: so(delphij,gtetlow)
Approved by: re(marius)
Differential Revision: https://reviews.freebsd.org/D16898
Now softc should be retrieved from struct edvev * pointer
with evdev_get_softc() helper.
wmt(4) is a sample of driver that support both KPI.
Reviewed by: hselasky, gonzo
Differential Revision: https://reviews.freebsd.org/D16614
Add support for the second channel to bcm2835_pwm driver. Configurable
parameters like mode, period, ratio are exposed as sysctls with postfix '2',
e.g.: dev.pwm.N.mode2, dev.pwm.N.period2, dev.pwm.N.ratio2
Second channel can be enabled in DTB by configuring pwn-2chan overlay
instead of pwm in config.txt. See [1]
[1] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README
Submitted by: Bob Frazier
Differential Revision: https://reviews.freebsd.org/D15769
SDHOST is another SD controller that is present on Raspberry Pi (the
other one is SDHC and handled by bcm2835_sdhci driver). Both
controllers are capable of providing interface to SD card, actual
configuration can be set in dtb file. At the moment custom DTBs for
RPi/RPi2 have sdhost node disabled. On RPi3 sdhost is disabled in
snapshot images by applying mmc.dtbo overlay. To enalbe both devices
user has to edit config.txt on FAT partition and remove or comment
"dtoverlay=mmc" line.
When no overlay applied on RPi3 SDHOST controls SD card and SDHC
interface can be used for SDIO. mmc.dtbo overlay disables SDHOST node
and switches SD card over to SDHC. Likewise sdhost.dtbo overlay (not
currently included in snapshot image, but can be obtained from firmare
repo[1]) disabled SDHC node and switch SD card over to SDHOST.
[1] https://github.com/raspberrypi/firmware/tree/master/boot/overlays
Submitted by: Klaus P. Ohrhallinger <k@7he.at>
Differential Revision: https://reviews.freebsd.org/D14168
and set up the hardware accordingly on each transfer. This replaces the old
configuration done via sysctl, and allows both fdt configuration data and
userland control via the spigen device to work.
Submitted by: Bob Frazier
Differential Revision: https://reviews.freebsd.org/D15031
r332839 changed number of cells per interrupt for local_intc from 1 to 2
to pass type of IRQ. Driver expected only 1 cell so after r332839
all interrupt children of local_intc failed to allocate IRQ resource.
Fix this regression by relaxing check for number of cells in interrupt
property to be either 1 or 2.
PR: 227904
Switch to standard FDT-base driver behavior and don't attach
if node "status" property value nn DTS is not set to "okay"
On RPi PWM by default is disabled, to enable it pwm.dtbo
from official repo[1] should be copied to overlays directory
on SD card FAT partition and "dtoverlay=pwm" line added to
config.txt. For more details see pwm overlay documentation[2]
sysutils/rpi-firmware port now includes overlays, so they
can be installed as a part of release image build.
[1] https://github.com/raspberrypi/firmware/tree/master/boot
[2] https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README
No objections from: phk@
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
On Raspberry Pi platform GPIO controller also responsible for pins
multiplexing. Pi code predates proper FDT support in FreeBSD so a
lot of pinmux info is hardcoded. This patch:
- Implements pinctl methods in bcm2835_gpio
- Converts all devices with ad-hoc pinmux info to proper pin control
mechanisms and adds pinmux info in FreeBSD's custom dts files.
- Adds fdt_pinctrl option to RPI2 and RPI-B kernels
- Adds SPI pinmux config to FreeBSD's customization of GNU DTS.
Reviewed by: imp, manu
Differential Revision: https://reviews.freebsd.org/D14104
OF_finddevices returns ((phandle_t)-1) in case of failure. Some code
in existing drivers checked return value to be equal to 0 or
less/equal to 0 which is also wrong because phandle_t is unsigned
type. Most of these checks were for negative cases that were never
triggered so trhere was no impact on functionality.
Reviewed by: nwhitehorn
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D14645
Upstream DTBs don't provide IRQ lines for the RNG. Moreover, harvesting
bytes as often as the RNG interrupt is triggered (87 times per sec) is an
overkill.
For these reasons, get rid of the interrupt mode and make callout mode the
default, with random bits harvested every 4 seconds.
Submitted by: Sylvain Garrigues <sylgar@gmail.com>
Reviewed by: ian, imp, manu, mmel
Approved by: emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D14541
instead of frobbing the registers directly.
As a hack the bcm2835_pwm kmod presently ignores the 'status="disabled"'
in the RPI3 DTB, assuming that if you load the kld you probably
want the PWM to work.
files that can use the default value.
It used to be required that the low-order bits of KERNVIRTADDR matched
the low-order bits of the physical load address for all arm platforms.
That hasn't been a requirement for armv6 platforms since FreeBSD 10.
There is no longer any relationship between load addr and KERNVIRTADDR
except that both must be aligned to a 2 MiB boundary.
This change makes the default KERNVIRTADDR value 0xc0000000, and removes the
options from all the platforms that can use the default value. The default
is now defined in vmparam.h, and that file is now included in a few new
places that reference KERNVIRTADDR, since it may not come in via the
forced-include of opt_global.h on the compile command line.
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
A comment in bcm_bsc_fill_tx_fifo() even lists sc_totlen > 0 as a
precondition for calling the routine. I apparently forgot to make the
code do what my comment said.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Since r324184 the root node compatible for rpi2 is "brcm,bcm2836", add
it to the compatible list of bcm2835_cpufreq.
Tested On: RPI2 v1.1 RPI2 v1.2
Reported by: many on freebsd-arm@
Transition all boards that support arm cortex CPUs to armv7. This
leaves two armv6 kernels in the tree. RPI-B, which uses the BCM2835
which has a ARM1176 core, and VERSATILEPB, which is a qemu board setup
around the time RPI-B went in. Copy std.armv6 to std.armv7, even
though that duplicates a lot of stuff. More work needs to be done to
sort out the duplication.
Differential Revision: https://reviews.freebsd.org/D12027
- Added more compatibility strings to drivers not yet converted
- Added new RPI platform code compatibility string to match the ones used
upstream
- Adapted RPI and RPI2 DTS to match the new platform code compatibility
string
The goal is to use the upstream DTBs as a replacement for our custom one.
This is now possible with these changes.
Additionally, as the RPI firmware automatically chooses the right DTB for
us, this would allow to have one common armv6 kernel for RPI0 and RPI1
(BCM2835-based), and one common armv7 kernel for RPI2 v1.1 (BCM2836-based),
and RPI2 v1.2 / RPI3 (BCM2837-based).
Submitted by: Sylvain Garrigues <sylgar@gmail.com>
Differential Revision: https://reviews.freebsd.org/D12360
common case where it's needed -- a write followed by a read to the same slave.
The i2c controller in this chip only performs complete transfers, it does
not provide control over start/repeat-start/stop operations on the bus.
Thus, we have gotten a full stop/start sequence rather than a repeat-start
when doing a typical i2c slave access of "write address, read data". Some
i2c slave devices require a repeat-start to work correctly.
These changes cause the controller to do a repeat-start by pre-staging the
read parameters in the controller registers immediate after the controller
has latched the values for the initial write operation, but before any
bytes are actually written. With the values pre-staged, when the write
portion of the transfer completes, the state machine in the silicon sees
a new start operation already staged and that causes it to perform a
repeat-start. The key to tricking the buggy hardware into doing this is
to avoid prefilling any output data in the transmit FIFO so that it is
possible to catch the silicon in the state where transmit values are
latched but the transmit isn't completed yet.
This change allows to just call sdhci_start_slot() in SDHCI drivers
and not to think about which stack handles the operation.
As a side effect, this will also fix MMCCAM with sdhci_acpi driver.
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D12471
* Demote the level of several debug messages to CAM_DEBUG_TRACE
* Add detection for SDHC cards that can do 1.8V. No voltage switch sequence
is issued yet;
* Don't create a separate LUN for each SDIO function. We need just one to make
pass(4) attach;
* Remove obsolete mmc_sdio* files. SDIO functionality will be moved into the
separate device that will manage a new sdio(4) bus;
* Terminate probing if got no reply to CMD0;
* Make bcm2835 SDHCI host controller driver compile with 'option MMCCAM'.
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D12109
available, in i2c controller drivers that require interrupts for transfers.
This is the result of auditing all 22 existing drivers that attach iicbus.
These drivers were the only ones remaining that require interrupts and were
not using config_intrhook to defer attachment. That has led, over the
years, to various i2c slave device drivers needing to use config_intrhook
themselves rather than performing bus transactions in their probe() and
attach() methods, just in case they were attached too early.
state to save power, so after writing the entry point address for a core to
the mailbox, use a dsb() to synchronize the execution pipeline to the data
written, then use an sev() to wake up the core.
Submitted by: Sylvain Garrigues <sylgar@gmail.com>
Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers from both the kernel and as
userland daemons are possible, though much of that functionality will
come later.
Some of the CAM integration isn't complete (there are sleeps in the
device probe state machine, for example), but those minor issues can
be improved in-tree more easily than out of tree and shouldn't gate
progress on other fronts. Appologies to reviews if specific items
have been overlooked.
Submitted by: Ilya Bakulin
Reviewed by: emaste, imp, mav, adrian, ian
Differential Review: https://reviews.freebsd.org/D4761
merge with first commit, various compile hacks.
FreeBSD uses upstream DTB for RPi3 build and compatibility string for
i2c device is different there. Add this new string to compatibility data.
Reported by: Karl Denninger
MFC after: 3 days
as kernel drivers and their dependency onto mmc(4); this allows for
incrementing the mmc(4) module version but also for entire omission
of these bridge declarations for mmccam(4) in a single place, i. e.
in dev/mmc/bridge.h.
comments, marking unused parameters as such, style(9), whitespace,
etc.
o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method (I've whipped these out of the tree as part of r227843
once, but they keep coming back ...),
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.
o Trim/adjust includes.
RPi3 cpufreq is more like that on RPi2. Setting arm frequency
above min (say, "sysctl hw.cpufreq.arm_freq=600000001") turns on
turbo mode, and the firmware automatically raises voltage, sets
frequency to max 1200MHz, and throttle when overheat, etc.
Swap if/else parts and use SOC_BCM2835 def so RPi3 can share the
same cpufreq logic as RPi2, instead of falling to that for RPi.
Submitted by: Jia-Shiun Li <jiashiun@gmail.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9640
- Use new option SMP_ON_UP instead of (mis)using specific CPU type.
By this, any SMP kernel can be compiled with SMP_ON_UP support.
- Enable runtime detection of CPU multiprocessor extensions only
if SMP_ON_UP option is used. In other cases (pure SMP or UP),
statically compile only required variant.
- Don't leak multiprocessor instructions to UP kernel.
- Correctly handle data cache write back to point of unification.
DCCMVAU is supported on all armv7 cpus.
- For SMP_ON_UP kernels, detect proper TTB flags on runtime.
Differential Revision: https://reviews.freebsd.org/D9133
Rework general approach to locking and working with audio worker thread:
- Use flags to signal requested worker action
- Fix submitted buffer calculations to avoid samples starvation
- Protect buffer pointers with locks to fix race condition between callback
and audio worker thread
- Remove unnecessary vchi_service_use
- Do not use lock to serialize VCHI requests since only one thread issues them now
- Fix unloading signaling per hselasky@ suggestion
- Add output to detect inconsistent callback data caused by possible firmware bug
https://github.com/raspberrypi/firmware/issues/696
- Add stats/debug sysctls to troubleshoot possible bugs
PR: 213687, 205979, 215194
MFC after: 1 week
As cs is stored in a uint32_t, use the last bit to store the
active high flag as it's unlikely that we will have that much CS.
Reviewed by: loos
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8614
Replace them with a default handler that returns devmap_lastaddr.
Reviewed by: mmel
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D8806
