Hide unused code under #ifdef notyet (in one case the only caller is under
that same ifdef), or if it is arm (not arm64) specific code under the
__arm__ ifdef to not yield -Wunused-function warnings during the arm64
kernel compile.
MFC after: 2 weeks
This allows SDIO (through CAM) to attach to an upstream, e.g.,
..
sdhci_bcm0 pnpinfo name=mmc@7e300000 compat=brcm,bcm2835-mmc
sdiob0
..
Without this, upon trying to load sdio, we would panic with
"bus_add_child is not implemented".
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
In the DMA case, given we disable the data interrupts, we never seem
to get DATA_END. Given we are relying on DMA interrupts we are not
using the SDHCI state machine and hence only call into
sdhci_platform_will_handle() for the first check of data.
We do not call "will handle" for any following round trips of the same
transaction if block size * count > BCM_DMA_BLOCK_SIZE.
Manually check "left" in the DMA interrupt handler to see if we have at
least another full BCM_DMA_BLOCK_SIZE to handle.
Without this change we would DMA that and then even start a DMA with
left == 0 which would lead to a timeout and error.
Now we re-enable data interrupts and return and let the SDHCI generic
interrupt handler and state machine pick the SPACE_AVAIL up and then
find that it should punt to the pio_handler for the remaining bytes
or finish the data transaction.
With this change block mode seems to work beyond 7 * 64byte blocks,
which worked as it was below BCM_DMA_BLOCK_SIZE.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20199
Extending what the initial revision, r273264, r276985, r277346 have
started for the transfer mode and command registers, another pair of
16bit registers written in sequence are block size and block count,
which fall together onto the same 32bit line and hence the same
register(s) would be written twice in sequence for those as well.
Use a similar approach to transfer mode and command and save the writes
to either of the block regiters and then only execute a write once.
We can do this as with transfer mode their values are meaningless until
a command is issued so we can use that write to command as a trigger
to also write out the block registers.
Compared to transfer mode and command the value of block count can
change, so we need to keep state and actually read the block registers
back the first time after a write.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20197
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.
occasional spurious interrupts are a normal thing on this hardware. Also,
change the name of the cpu-local interrupt controller driver from local_intc
to lintc, because the name gets built into interrupt names, which have to
fit into a 19-byte field for stats reporting (so this allows 5 more bytes
of the actual interrupt name to be displayed).
Since r324184 the root node compatible for the original Raspberry Pi
is "brcm,bcm2835", add it to the compatible list of bcm2835_cpufreq.
Tested On: RPi1 Model B
Note that the default Das U-Boot FDT does not include a cpus clause
so actually adding a bcm2835_cpufreq device requires adding a FDT
overlay defining the cpu.
Approved by: grog, jhb (mentors)
MFC after: 3 days
Similar to bcm2835_sdhost.c add a TUNABLE and SYSCTL to selectively
turn on debugging printfs if debugging is turned on at compile time.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Reviewed by: gonzo, andrew
Differential Revision: https://reviews.freebsd.org/D19745
front-end doesn't support SDMA or the latter implements a platform-
specific transfer method instead. While at it, factor out allocation
and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to
keep the code more readable when adding support for ADMA variants.
o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum
of 512 KiB instead of using a fixed 4-KiB-buffer. With the default
MAXPHYS of 128 KiB and depending on the controller and medium, this
reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on
sequential reads while an increase of throughput of up to ~84 % was
seen.
Front-ends for broken controllers that only support an SDMA buffer
boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY
and supply a size via struct sdhci_slot. According to Linux, only
Qualcomm MSM-type SDHCI controllers are affected by this, though.
Requested by: Shreyank Amartya (unconditional bump to 512 KiB)
o Introduce a SDHCI_DEPEND macro for specifying the dependency of the
front-end modules on the sdhci(4) one and bump the module version
of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order
to ensure that all components are in sync WRT struct sdhci_slot.
o In sdhci(4):
- Make pointers const were applicable,
- replace a few device_printf(9) calls with slot_printf() for
consistency, and
- sync some local functions with their prototypes WRT static.
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