Some applications (e.g. Kodi) use tvservice APIs to manage HDMI
modes, power state, EDID etc. directly through VideoCore. After
these manipulations VideoCore may loose its state and needs to be
resynced with ARM. Under Linux this problem is worked around using
fbset utility that recreates framebuffer. Since there is no fbset
utility in FreeBSD we provide sysctl for userland apps to get system
back into normal mode.
interrupt status register to process shared interrupts only if the bit
is active and only on core to which they are routed.
Reviewed by: imp, loos
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D3723
- Add bcm2835_mbox_property for generic property request, it accepts
pointer to prepared property chan message and its size, forwards
it to MBOX and copies result back
- Make all bcm2835_mbox_XXX functions that use property channel go
through bcm2835_mbox_property path. Do not accept device_t as
an argument, it's not required: all DMA operatiosn should go
through mbox device, and all API consumers should report errors
on their side.
receives video memory address from VideoCore through property mailbox
channel. Older versions of firmware (and the one that is currently part
of sysutils/u-boot-rpi and sysutils/u-boot-rpi2) returned real physical
address, newer one returns VideoCore bus address, so we need to convert
it to actual physical address. this version works with both older and
newer interface.
missed. In other words, if a new request for an IPI is sent while the
previous request is being handled but the IPI is not cleared yet, the
clearing of the previous IPI request also clears the new one and the
handling is missed.
There are only three MP interrupt controllers in ARM now. Two of them are
fixed by this change, the third one is correct, probably only just by
accident. The fix is minimalistic as new interrupt framework is awaited.
It was debugged on RPi2 where missing IPI handling together with SCHED_ULE
led to situation in which tdq_ipipending was not cleared and so IPI_PREEMPT
was stopped to be sent. Various odditys were found related to slow system
response time like various events timed out, and slow console response.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
Reviewed by: loos, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3722
Use the BCM2835_MBOX_CHAN_PROP mbox channel to setup the framebuffer,
remove DMA code (its now done in bcm2835_mbox.c).
Also adjust the color palette when bcm2708_fb.fbswap is set. The
firmware used on RPi 2 uses this mode.
Tested on: RPi-B and RPi 2 with 16, 24 and 32bpp
Note: The 32bpp mode on RPi-B has the red and blue swapped, this
is a know problem (not a driver problem).
Use the BCM2835_MBOX_CHAN_PROP mbox channel to setup the framebuffer,
remove unused code and unnecessary includes.
Adjust the color palette when bcm2708_fb.fbswap is set on /chosen/bootargs
node of DTB. The firmware used on RPi 2 uses this mode.
Tested on: RPi-B and RPi 2 with 16, 24 and 32bpp
BCM2835_MBOX_CHAN_PROP channel. The old channel (BCM2835_MBOX_CHAN_FB)
seems deprecated on recent firmware versions and is causing a freeze on
RPi 2.
The actual changes in the framebuffer drivers will follow in subsequent
commits.
the Raspberry Pi B we support most of the devices are already supported,
however the base address has changed.
A few items are not working, or missing. The main ones are:
* DMA doesn't work in the sdhci driver.
* Enabling vchiq halts the boot, may be interrupt related.
* There is no U-Boot port yet so the DTB is embedded in the kernel.
The last point will make it difficult to boot FreeBSD, however there is
support for the Raspberry Pi 2 in the U-Boot git repo. As I have not tested
this it is left as an open task to create a port to build.
X-MFC: When the above issues are fixed
Sponsored by: ABT Systems Ltd
to get the default frequency of the sdhci device.
While here use a u_int to hold the frequency as it may be too large to fit
in a 32-bit signed integer. This is the case when we have a 250MHz clock.
been done by U-Boot. This allows the USB to work when we load the kernel
directly.
No dma sync is performed after these operations as the data we read/write
is not used by the cpu after the calls to the maimbox driver.
Differential Revision: https://reviews.freebsd.org/D1940
Reviewed by: imp, Michal Meloun (meloun AT miracle.cz)
MFC after: 1 Week
Sponsored by: ABT Systems Ltd
