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
- Initialize lock before starting worker process
- Do not hold lock when destroying evdev. By that time ther should be no
other active code pathes that can access softc
VM_MEMATTR_WRITE_COMBINING sets write-through cache flag for framebuffer
memory that prevents pixel data from being stuck in cache until evicition
happens
100 cycles per us seems accurate enough, at least it's better than the 200 value
that was used before.
Reviewed by: andrew, imp
Differential Revision: https://reviews.freebsd.org/D8062
Technically touchscreen chip is FT5406 but all hardware
communication is performed by VideCore and only final results
are presented to ARM part through memory region shared between
VC and ARM.
evdev is used as userland interface. FT5406 supports up to
10 touchpoints, but for now driver emulates single touch device
because I do not have GUI bits to test this functionality.
Driver is not enabled in default config for RPI and RPI2
Tested with: evdev-dump, tslib
