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
- Move all VCHI activity to worker thread: channel methods are called with
non-sleepable lock held and VCHI uses sleepable lock.
- In worker thread use sx(9) lock instead of mutex(9) for the same reason.
PR: 213801, 205979
- Rename SOC_BCM2837 to SOC_BRCM_BCM2837, put it to opt_soc.h
- do not use files.XXX files, just move required sources to
conf/files.arm64 and make them depend on soc_brcm_bcm2837
Suggested by: andrew
RPI3 kernel config builds kernel compatible with latest upstream device
tree and firmware: https://github.com/raspberrypi/firmware/tree/master/boot
As of today it's 597c662a613df1144a6bc43e5f4505d83bd748ca
Default console is PL01x, so pi3-disable-bt dt overlay should be configured
in config.txt and stock U-Boot should be patched to use proper serial port.
Yet unsupported: SMP, VCHIQ, RNG driver. RNG requires some work due to
upstream device tree incompatibility.
Multiple people contributed to this work over time: db@, loos@, manu@
- Revert BUS_SPACE_PHYSADDR back to rman_get_start. BUS_SPACE_PHYSADDR was
introduced in 2013 as temporary wrapper until proper solution appears.
It's ARM only and since we need this file for ARM64 build and no proper
API has been introduced - just revert the change and make sure it's
going to appear when people grep for BUS_SPACE_PHYSADDR in sources.
- Fix printf format for size_t variables
If pass order is not specified devices are attached in the order they are
defined in dts. Some interrupt consumers may be defined before intc. Also
make sure intc interrupt-parent local_intc is attached before intc itself.
- Fix compatibility strings
- Properly decode upstream's two-cell interrupt specs. Our home-made dts
does not have two-cell interrupts so no need to preserve backward
compatibility
- Add multitouch support (protocol B)
- Report physical size of the screen
- Switch from using busy loop to callbacks
- Enable callbacks only when there is active listener on /dev/input/eventX
Submitted by: Vladimir Kondratiev <wulf@cicgroup.ru>
for later Cortex-A CPUs that support the Multiprocessor Extensions. This
will be needed to support both in a single GENERIC kernel while still
being able to only build for a single SoC.
Reviewed by: mmel
Relnotes: yes
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D8138
