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
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.
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.
used for kernel devices it is used by i2c(8).
This fix the 'error: Device not configured' when i2c(8) tries to reset the
controller, as an example:
# i2c -r
Resetting I2C controller on /dev/iic0: error: Device not configured
For now use conservative settings for default i2c speeds.
MFC after: 1 week
rely only on checking the device unit to indentify the BSC unit we are
attaching to. Make use of the device base address to identify our BSC unit.
Approved by: adrian (mentor)
