mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
Merge tag 'char-misc-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH: "Here is the big pull request for char/misc drivers for 4.16-rc1. There's a lot of stuff in here. Three new driver subsystems were added for various types of hardware busses: - siox - slimbus - soundwire as well as a new vboxguest subsystem for the VirtualBox hypervisor drivers. There's also big updates from the FPGA subsystem, lots of Android binder fixes, the usual handful of hyper-v updates, and lots of other smaller driver updates. All of these have been in linux-next for a long time, with no reported issues" * tag 'char-misc-4.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (155 commits) char: lp: use true or false for boolean values android: binder: use VM_ALLOC to get vm area android: binder: Use true and false for boolean values lkdtm: fix handle_irq_event symbol for INT_HW_IRQ_EN EISA: Delete error message for a failed memory allocation in eisa_probe() EISA: Whitespace cleanup misc: remove AVR32 dependencies virt: vbox: Add error mapping for VERR_INVALID_NAME and VERR_NO_MORE_FILES soundwire: Fix a signedness bug uio_hv_generic: fix new type mismatch warnings uio_hv_generic: fix type mismatch warnings auxdisplay: img-ascii-lcd: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE uio_hv_generic: add rescind support uio_hv_generic: check that host supports monitor page uio_hv_generic: create send and receive buffers uio: document uio_hv_generic regions doc: fix documentation about uio_hv_generic vmbus: add monitor_id and subchannel_id to sysfs per channel vmbus: fix ABI documentation uio_hv_generic: use ISR callback method ...
This commit is contained in:
Linus Torvalds
@@ -42,72 +42,93 @@ Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The 16 bit vendor ID of the device
|
||||
Users: tools/hv/lsvmbus and user level RDMA libraries
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/cpu
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Directory for per-channel information
|
||||
NN is the VMBUS relid associtated with the channel.
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/cpu
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: VCPU (sub)channel is affinitized to
|
||||
Users: tools/hv/lsvmbus and other debuggig tools
|
||||
Users: tools/hv/lsvmbus and other debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/cpu
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/cpu
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: VCPU (sub)channel is affinitized to
|
||||
Users: tools/hv/lsvmbus and other debuggig tools
|
||||
Users: tools/hv/lsvmbus and other debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/in_mask
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/in_mask
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Inbound channel signaling state
|
||||
Description: Host to guest channel interrupt mask
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/latency
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/latency
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Channel signaling latency
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/out_mask
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/out_mask
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Outbound channel signaling state
|
||||
Description: Guest to host channel interrupt mask
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/pending
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/pending
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Channel interrupt pending state
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/read_avail
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/read_avail
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Bytes availabble to read
|
||||
Description: Bytes available to read
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/write_avail
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/write_avail
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Bytes availabble to write
|
||||
Description: Bytes available to write
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/events
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/events
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Number of times we have signaled the host
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/interrupts
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/interrupts
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Number of times we have taken an interrupt (incoming)
|
||||
Users: Debugging tools
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/subchannel_id
|
||||
Date: January. 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Subchannel ID associated with VMBUS channel
|
||||
Users: Debugging tools and userspace drivers
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/monitor_id
|
||||
Date: January. 2018
|
||||
KernelVersion: 4.16
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: Monitor bit associated with channel
|
||||
Users: Debugging tools and userspace drivers
|
||||
|
||||
@@ -0,0 +1,87 @@
|
||||
What: /sys/bus/siox/devices/siox-X/active
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
On reading represents the current state of the bus. If it
|
||||
contains a "0" the bus is stopped and connected devices are
|
||||
expected to not do anything because their watchdog triggered.
|
||||
When the file contains a "1" the bus is operated and periodically
|
||||
does a push-pull cycle to write and read data from the
|
||||
connected devices.
|
||||
When writing a "0" or "1" the bus moves to the described state.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X/device_add
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Write-only file. Write
|
||||
|
||||
<type> <inbytes> <outbytes> <statustype>
|
||||
|
||||
to add a new device dynamically. <type> is the name that is used to match
|
||||
to a driver (similar to the platform bus). <inbytes> and <outbytes> define
|
||||
the length of the input and output shift register in bytes respectively.
|
||||
<statustype> defines the 4 bit device type that is check to identify connection
|
||||
problems.
|
||||
The new device is added to the end of the existing chain.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X/device_remove
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Write-only file. A single write removes the last device in the siox chain.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X/poll_interval_ns
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Defines the interval between two poll cycles in nano seconds.
|
||||
Note this is rounded to jiffies on writing. On reading the current value
|
||||
is returned.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/connected
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Read-only value. "0" means the Yth device on siox bus X isn't "connected" i.e.
|
||||
communication with it is not ensured. "1" signals a working connection.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/inbytes
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Read-only value reporting the inbytes value provided to siox-X/device_add
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/status_errors
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Counts the number of time intervals when the read status byte doesn't yield the
|
||||
expected value.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/type
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Read-only value reporting the type value provided to siox-X/device_add.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/watchdog
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Read-only value reporting if the watchdog of the siox device is
|
||||
active. "0" means the watchdog is not active and the device is expected to
|
||||
be operational. "1" means the watchdog keeps the device in reset.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/watchdog_errors
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Read-only value reporting the number to time intervals when the
|
||||
watchdog was active.
|
||||
|
||||
What: /sys/bus/siox/devices/siox-X-Y/outbytes
|
||||
KernelVersion: 4.16
|
||||
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
||||
Description:
|
||||
Read-only value reporting the outbytes value provided to siox-X/device_add.
|
||||
@@ -11,7 +11,9 @@ Required properties:
|
||||
- spi-max-frequency : max spi frequency to use
|
||||
- pagesize : size of the eeprom page
|
||||
- size : total eeprom size in bytes
|
||||
- address-width : number of address bits (one of 8, 16, or 24)
|
||||
- address-width : number of address bits (one of 8, 9, 16, or 24).
|
||||
For 9 bits, the MSB of the address is sent as bit 3 of the instruction
|
||||
byte, before the address byte.
|
||||
|
||||
Optional properties:
|
||||
- spi-cpha : SPI shifted clock phase, as per spi-bus bindings.
|
||||
|
||||
@@ -6,12 +6,17 @@ Required properties:
|
||||
- "rockchip,rk3188-efuse" - for RK3188 SoCs.
|
||||
- "rockchip,rk3228-efuse" - for RK3228 SoCs.
|
||||
- "rockchip,rk3288-efuse" - for RK3288 SoCs.
|
||||
- "rockchip,rk3328-efuse" - for RK3328 SoCs.
|
||||
- "rockchip,rk3368-efuse" - for RK3368 SoCs.
|
||||
- "rockchip,rk3399-efuse" - for RK3399 SoCs.
|
||||
- reg: Should contain the registers location and exact eFuse size
|
||||
- clocks: Should be the clock id of eFuse
|
||||
- clock-names: Should be "pclk_efuse"
|
||||
|
||||
Optional properties:
|
||||
- rockchip,efuse-size: Should be exact eFuse size in byte, the eFuse
|
||||
size in property <reg> will be invalid if define this property.
|
||||
|
||||
Deprecated properties:
|
||||
- compatible: "rockchip,rockchip-efuse"
|
||||
Old efuse compatible value compatible to rk3066a, rk3188 and rk3288
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
Eckelmann SIOX GPIO bus
|
||||
|
||||
Required properties:
|
||||
- compatible : "eckelmann,siox-gpio"
|
||||
- din-gpios, dout-gpios, dclk-gpios, dld-gpios: references gpios for the
|
||||
corresponding bus signals.
|
||||
|
||||
Examples:
|
||||
|
||||
siox {
|
||||
compatible = "eckelmann,siox-gpio";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_siox>;
|
||||
|
||||
din-gpios = <&gpio6 11 0>;
|
||||
dout-gpios = <&gpio6 8 0>;
|
||||
dclk-gpios = <&gpio6 9 0>;
|
||||
dld-gpios = <&gpio6 10 0>;
|
||||
};
|
||||
@@ -0,0 +1,50 @@
|
||||
SLIM(Serial Low Power Interchip Media Bus) bus
|
||||
|
||||
SLIMbus is a 2-wire bus, and is used to communicate with peripheral
|
||||
components like audio-codec.
|
||||
|
||||
Required property for SLIMbus controller node:
|
||||
- compatible - name of SLIMbus controller
|
||||
|
||||
Child nodes:
|
||||
Every SLIMbus controller node can contain zero or more child nodes
|
||||
representing slave devices on the bus. Every SLIMbus slave device is
|
||||
uniquely determined by the enumeration address containing 4 fields:
|
||||
Manufacturer ID, Product code, Device index, and Instance value for
|
||||
the device.
|
||||
If child node is not present and it is instantiated after device
|
||||
discovery (slave device reporting itself present).
|
||||
|
||||
In some cases it may be necessary to describe non-probeable device
|
||||
details such as non-standard ways of powering up a device. In
|
||||
such cases, child nodes for those devices will be present as
|
||||
slaves of the SLIMbus controller, as detailed below.
|
||||
|
||||
Required property for SLIMbus child node if it is present:
|
||||
- reg - Should be ('Device index', 'Instance ID') from SLIMbus
|
||||
Enumeration Address.
|
||||
Device Index Uniquely identifies multiple Devices within
|
||||
a single Component.
|
||||
Instance ID Is for the cases where multiple Devices of the
|
||||
same type or Class are attached to the bus.
|
||||
|
||||
- compatible -"slimMID,PID". The textual representation of Manufacturer ID,
|
||||
Product Code, shall be in lower case hexadecimal with leading
|
||||
zeroes suppressed
|
||||
|
||||
SLIMbus example for Qualcomm's slimbus manager component:
|
||||
|
||||
slim@28080000 {
|
||||
compatible = "qcom,apq8064-slim", "qcom,slim";
|
||||
reg = <0x28080000 0x2000>,
|
||||
interrupts = <0 33 0>;
|
||||
clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
|
||||
clock-names = "iface", "core";
|
||||
#address-cells = <2>;
|
||||
#size-cell = <0>;
|
||||
|
||||
codec: wcd9310@1,0{
|
||||
compatible = "slim217,60";
|
||||
reg = <1 0>;
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,39 @@
|
||||
Qualcomm SLIMbus controller
|
||||
This controller is used if applications processor driver controls SLIMbus
|
||||
master component.
|
||||
|
||||
Required properties:
|
||||
|
||||
- #address-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
|
||||
- #size-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
|
||||
|
||||
- reg : Offset and length of the register region(s) for the device
|
||||
- reg-names : Register region name(s) referenced in reg above
|
||||
Required register resource entries are:
|
||||
"ctrl": Physical address of controller register blocks
|
||||
"slew": required for "qcom,apq8064-slim" SOC.
|
||||
- compatible : should be "qcom,<SOC-NAME>-slim" for SOC specific compatible
|
||||
followed by "qcom,slim" for fallback.
|
||||
- interrupts : Interrupt number used by this controller
|
||||
- clocks : Interface and core clocks used by this SLIMbus controller
|
||||
- clock-names : Required clock-name entries are:
|
||||
"iface" : Interface clock for this controller
|
||||
"core" : Interrupt for controller core's BAM
|
||||
|
||||
Example:
|
||||
|
||||
slim@28080000 {
|
||||
compatible = "qcom,apq8064-slim", "qcom,slim";
|
||||
reg = <0x28080000 0x2000>, <0x80207C 4>;
|
||||
reg-names = "ctrl", "slew";
|
||||
interrupts = <0 33 0>;
|
||||
clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
|
||||
clock-names = "iface", "core";
|
||||
#address-cells = <2>;
|
||||
#size-cell = <0>;
|
||||
|
||||
wcd9310: audio-codec@1,0{
|
||||
compatible = "slim217,60";
|
||||
reg = <1 0>;
|
||||
};
|
||||
};
|
||||
@@ -97,6 +97,7 @@ dptechnics DPTechnics
|
||||
dragino Dragino Technology Co., Limited
|
||||
ea Embedded Artists AB
|
||||
ebv EBV Elektronik
|
||||
eckelmann Eckelmann AG
|
||||
edt Emerging Display Technologies
|
||||
eeti eGalax_eMPIA Technology Inc
|
||||
elan Elan Microelectronic Corp.
|
||||
|
||||
@@ -47,6 +47,8 @@ available subsections can be seen below.
|
||||
gpio
|
||||
misc_devices
|
||||
dmaengine/index
|
||||
slimbus
|
||||
soundwire/index
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
||||
@@ -0,0 +1,127 @@
|
||||
============================
|
||||
Linux kernel SLIMbus support
|
||||
============================
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
What is SLIMbus?
|
||||
----------------
|
||||
SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by
|
||||
MIPI (Mobile Industry Processor Interface) alliance. The bus uses master/slave
|
||||
configuration, and is a 2-wire multi-drop implementation (clock, and data).
|
||||
|
||||
Currently, SLIMbus is used to interface between application processors of SoCs
|
||||
(System-on-Chip) and peripheral components (typically codec). SLIMbus uses
|
||||
Time-Division-Multiplexing to accommodate multiple data channels, and
|
||||
a control channel.
|
||||
|
||||
The control channel is used for various control functions such as bus
|
||||
management, configuration and status updates. These messages can be unicast (e.g.
|
||||
reading/writing device specific values), or multicast (e.g. data channel
|
||||
reconfiguration sequence is a broadcast message announced to all devices)
|
||||
|
||||
A data channel is used for data-transfer between 2 SLIMbus devices. Data
|
||||
channel uses dedicated ports on the device.
|
||||
|
||||
Hardware description:
|
||||
---------------------
|
||||
SLIMbus specification has different types of device classifications based on
|
||||
their capabilities.
|
||||
A manager device is responsible for enumeration, configuration, and dynamic
|
||||
channel allocation. Every bus has 1 active manager.
|
||||
|
||||
A generic device is a device providing application functionality (e.g. codec).
|
||||
|
||||
Framer device is responsible for clocking the bus, and transmitting frame-sync
|
||||
and framing information on the bus.
|
||||
|
||||
Each SLIMbus component has an interface device for monitoring physical layer.
|
||||
|
||||
Typically each SoC contains SLIMbus component having 1 manager, 1 framer device,
|
||||
1 generic device (for data channel support), and 1 interface device.
|
||||
External peripheral SLIMbus component usually has 1 generic device (for
|
||||
functionality/data channel support), and an associated interface device.
|
||||
The generic device's registers are mapped as 'value elements' so that they can
|
||||
be written/read using SLIMbus control channel exchanging control/status type of
|
||||
information.
|
||||
In case there are multiple framer devices on the same bus, manager device is
|
||||
responsible to select the active-framer for clocking the bus.
|
||||
|
||||
Per specification, SLIMbus uses "clock gears" to do power management based on
|
||||
current frequency and bandwidth requirements. There are 10 clock gears and each
|
||||
gear changes the SLIMbus frequency to be twice its previous gear.
|
||||
|
||||
Each device has a 6-byte enumeration-address and the manager assigns every
|
||||
device with a 1-byte logical address after the devices report presence on the
|
||||
bus.
|
||||
|
||||
Software description:
|
||||
---------------------
|
||||
There are 2 types of SLIMbus drivers:
|
||||
|
||||
slim_controller represents a 'controller' for SLIMbus. This driver should
|
||||
implement duties needed by the SoC (manager device, associated
|
||||
interface device for monitoring the layers and reporting errors, default
|
||||
framer device).
|
||||
|
||||
slim_device represents the 'generic device/component' for SLIMbus, and a
|
||||
slim_driver should implement driver for that slim_device.
|
||||
|
||||
Device notifications to the driver:
|
||||
-----------------------------------
|
||||
Since SLIMbus devices have mechanisms for reporting their presence, the
|
||||
framework allows drivers to bind when corresponding devices report their
|
||||
presence on the bus.
|
||||
However, it is possible that the driver needs to be probed
|
||||
first so that it can enable corresponding SLIMbus device (e.g. power it up and/or
|
||||
take it out of reset). To support that behavior, the framework allows drivers
|
||||
to probe first as well (e.g. using standard DeviceTree compatibility field).
|
||||
This creates the necessity for the driver to know when the device is functional
|
||||
(i.e. reported present). device_up callback is used for that reason when the
|
||||
device reports present and is assigned a logical address by the controller.
|
||||
|
||||
Similarly, SLIMbus devices 'report absent' when they go down. A 'device_down'
|
||||
callback notifies the driver when the device reports absent and its logical
|
||||
address assignment is invalidated by the controller.
|
||||
|
||||
Another notification "boot_device" is used to notify the slim_driver when
|
||||
controller resets the bus. This notification allows the driver to take necessary
|
||||
steps to boot the device so that it's functional after the bus has been reset.
|
||||
|
||||
Driver and Controller APIs:
|
||||
--------------------------
|
||||
.. kernel-doc:: include/linux/slimbus.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/slimbus/slimbus.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/slimbus/core.c
|
||||
:export:
|
||||
|
||||
Clock-pause:
|
||||
------------
|
||||
SLIMbus mandates that a reconfiguration sequence (known as clock-pause) be
|
||||
broadcast to all active devices on the bus before the bus can enter low-power
|
||||
mode. Controller uses this sequence when it decides to enter low-power mode so
|
||||
that corresponding clocks and/or power-rails can be turned off to save power.
|
||||
Clock-pause is exited by waking up framer device (if controller driver initiates
|
||||
exiting low power mode), or by toggling the data line (if a slave device wants
|
||||
to initiate it).
|
||||
|
||||
Clock-pause APIs:
|
||||
~~~~~~~~~~~~~~~~~
|
||||
.. kernel-doc:: drivers/slimbus/sched.c
|
||||
:export:
|
||||
|
||||
Messaging:
|
||||
----------
|
||||
The framework supports regmap and read/write apis to exchange control-information
|
||||
with a SLIMbus device. APIs can be synchronous or asynchronous.
|
||||
The header file <linux/slimbus.h> has more documentation about messaging APIs.
|
||||
|
||||
Messaging APIs:
|
||||
~~~~~~~~~~~~~~~
|
||||
.. kernel-doc:: drivers/slimbus/messaging.c
|
||||
:export:
|
||||
@@ -0,0 +1,15 @@
|
||||
=======================
|
||||
SoundWire Documentation
|
||||
=======================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
summary
|
||||
|
||||
.. only:: subproject
|
||||
|
||||
Indices
|
||||
=======
|
||||
|
||||
* :ref:`genindex`
|
||||
@@ -0,0 +1,207 @@
|
||||
===========================
|
||||
SoundWire Subsystem Summary
|
||||
===========================
|
||||
|
||||
SoundWire is a new interface ratified in 2015 by the MIPI Alliance.
|
||||
SoundWire is used for transporting data typically related to audio
|
||||
functions. SoundWire interface is optimized to integrate audio devices in
|
||||
mobile or mobile inspired systems.
|
||||
|
||||
SoundWire is a 2-pin multi-drop interface with data and clock line. It
|
||||
facilitates development of low cost, efficient, high performance systems.
|
||||
Broad level key features of SoundWire interface include:
|
||||
|
||||
(1) Transporting all of payload data channels, control information, and setup
|
||||
commands over a single two-pin interface.
|
||||
|
||||
(2) Lower clock frequency, and hence lower power consumption, by use of DDR
|
||||
(Dual Data Rate) data transmission.
|
||||
|
||||
(3) Clock scaling and optional multiple data lanes to give wide flexibility
|
||||
in data rate to match system requirements.
|
||||
|
||||
(4) Device status monitoring, including interrupt-style alerts to the Master.
|
||||
|
||||
The SoundWire protocol supports up to eleven Slave interfaces. All the
|
||||
interfaces share the common Bus containing data and clock line. Each of the
|
||||
Slaves can support up to 14 Data Ports. 13 Data Ports are dedicated to audio
|
||||
transport. Data Port0 is dedicated to transport of Bulk control information,
|
||||
each of the audio Data Ports (1..14) can support up to 8 Channels in
|
||||
transmit or receiving mode (typically fixed direction but configurable
|
||||
direction is enabled by the specification). Bandwidth restrictions to
|
||||
~19.2..24.576Mbits/s don't however allow for 11*13*8 channels to be
|
||||
transmitted simultaneously.
|
||||
|
||||
Below figure shows an example of connectivity between a SoundWire Master and
|
||||
two Slave devices. ::
|
||||
|
||||
+---------------+ +---------------+
|
||||
| | Clock Signal | |
|
||||
| Master |-------+-------------------------------| Slave |
|
||||
| Interface | | Data Signal | Interface 1 |
|
||||
| |-------|-------+-----------------------| |
|
||||
+---------------+ | | +---------------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+--+-------+--+
|
||||
| |
|
||||
| Slave |
|
||||
| Interface 2 |
|
||||
| |
|
||||
+-------------+
|
||||
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
The MIPI SoundWire specification uses the term 'device' to refer to a Master
|
||||
or Slave interface, which of course can be confusing. In this summary and
|
||||
code we use the term interface only to refer to the hardware. We follow the
|
||||
Linux device model by mapping each Slave interface connected on the bus as a
|
||||
device managed by a specific driver. The Linux SoundWire subsystem provides
|
||||
a framework to implement a SoundWire Slave driver with an API allowing
|
||||
3rd-party vendors to enable implementation-defined functionality while
|
||||
common setup/configuration tasks are handled by the bus.
|
||||
|
||||
Bus:
|
||||
Implements SoundWire Linux Bus which handles the SoundWire protocol.
|
||||
Programs all the MIPI-defined Slave registers. Represents a SoundWire
|
||||
Master. Multiple instances of Bus may be present in a system.
|
||||
|
||||
Slave:
|
||||
Registers as SoundWire Slave device (Linux Device). Multiple Slave devices
|
||||
can register to a Bus instance.
|
||||
|
||||
Slave driver:
|
||||
Driver controlling the Slave device. MIPI-specified registers are controlled
|
||||
directly by the Bus (and transmitted through the Master driver/interface).
|
||||
Any implementation-defined Slave register is controlled by Slave driver. In
|
||||
practice, it is expected that the Slave driver relies on regmap and does not
|
||||
request direct register access.
|
||||
|
||||
Programming interfaces (SoundWire Master interface Driver)
|
||||
==========================================================
|
||||
|
||||
SoundWire Bus supports programming interfaces for the SoundWire Master
|
||||
implementation and SoundWire Slave devices. All the code uses the "sdw"
|
||||
prefix commonly used by SoC designers and 3rd party vendors.
|
||||
|
||||
Each of the SoundWire Master interfaces needs to be registered to the Bus.
|
||||
Bus implements API to read standard Master MIPI properties and also provides
|
||||
callback in Master ops for Master driver to implement its own functions that
|
||||
provides capabilities information. DT support is not implemented at this
|
||||
time but should be trivial to add since capabilities are enabled with the
|
||||
``device_property_`` API.
|
||||
|
||||
The Master interface along with the Master interface capabilities are
|
||||
registered based on board file, DT or ACPI.
|
||||
|
||||
Following is the Bus API to register the SoundWire Bus:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int sdw_add_bus_master(struct sdw_bus *bus)
|
||||
{
|
||||
if (!bus->dev)
|
||||
return -ENODEV;
|
||||
|
||||
mutex_init(&bus->lock);
|
||||
INIT_LIST_HEAD(&bus->slaves);
|
||||
|
||||
/* Check ACPI for Slave devices */
|
||||
sdw_acpi_find_slaves(bus);
|
||||
|
||||
/* Check DT for Slave devices */
|
||||
sdw_of_find_slaves(bus);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
This will initialize sdw_bus object for Master device. "sdw_master_ops" and
|
||||
"sdw_master_port_ops" callback functions are provided to the Bus.
|
||||
|
||||
"sdw_master_ops" is used by Bus to control the Bus in the hardware specific
|
||||
way. It includes Bus control functions such as sending the SoundWire
|
||||
read/write messages on Bus, setting up clock frequency & Stream
|
||||
Synchronization Point (SSP). The "sdw_master_ops" structure abstracts the
|
||||
hardware details of the Master from the Bus.
|
||||
|
||||
"sdw_master_port_ops" is used by Bus to setup the Port parameters of the
|
||||
Master interface Port. Master interface Port register map is not defined by
|
||||
MIPI specification, so Bus calls the "sdw_master_port_ops" callback
|
||||
function to do Port operations like "Port Prepare", "Port Transport params
|
||||
set", "Port enable and disable". The implementation of the Master driver can
|
||||
then perform hardware-specific configurations.
|
||||
|
||||
Programming interfaces (SoundWire Slave Driver)
|
||||
===============================================
|
||||
|
||||
The MIPI specification requires each Slave interface to expose a unique
|
||||
48-bit identifier, stored in 6 read-only dev_id registers. This dev_id
|
||||
identifier contains vendor and part information, as well as a field enabling
|
||||
to differentiate between identical components. An additional class field is
|
||||
currently unused. Slave driver is written for a specific vendor and part
|
||||
identifier, Bus enumerates the Slave device based on these two ids.
|
||||
Slave device and driver match is done based on these two ids . Probe
|
||||
of the Slave driver is called by Bus on successful match between device and
|
||||
driver id. A parent/child relationship is enforced between Master and Slave
|
||||
devices (the logical representation is aligned with the physical
|
||||
connectivity).
|
||||
|
||||
The information on Master/Slave dependencies is stored in platform data,
|
||||
board-file, ACPI or DT. The MIPI Software specification defines additional
|
||||
link_id parameters for controllers that have multiple Master interfaces. The
|
||||
dev_id registers are only unique in the scope of a link, and the link_id
|
||||
unique in the scope of a controller. Both dev_id and link_id are not
|
||||
necessarily unique at the system level but the parent/child information is
|
||||
used to avoid ambiguity.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
static const struct sdw_device_id slave_id[] = {
|
||||
SDW_SLAVE_ENTRY(0x025d, 0x700, 0),
|
||||
{},
|
||||
};
|
||||
MODULE_DEVICE_TABLE(sdw, slave_id);
|
||||
|
||||
static struct sdw_driver slave_sdw_driver = {
|
||||
.driver = {
|
||||
.name = "slave_xxx",
|
||||
.pm = &slave_runtime_pm,
|
||||
},
|
||||
.probe = slave_sdw_probe,
|
||||
.remove = slave_sdw_remove,
|
||||
.ops = &slave_slave_ops,
|
||||
.id_table = slave_id,
|
||||
};
|
||||
|
||||
|
||||
For capabilities, Bus implements API to read standard Slave MIPI properties
|
||||
and also provides callback in Slave ops for Slave driver to implement own
|
||||
function that provides capabilities information. Bus needs to know a set of
|
||||
Slave capabilities to program Slave registers and to control the Bus
|
||||
reconfigurations.
|
||||
|
||||
Future enhancements to be done
|
||||
==============================
|
||||
|
||||
(1) Bulk Register Access (BRA) transfers.
|
||||
|
||||
|
||||
(2) Multiple data lane support.
|
||||
|
||||
Links
|
||||
=====
|
||||
|
||||
SoundWire MIPI specification 1.1 is available at:
|
||||
https://members.mipi.org/wg/All-Members/document/70290
|
||||
|
||||
SoundWire MIPI DisCo (Discovery and Configuration) specification is
|
||||
available at:
|
||||
https://www.mipi.org/specifications/mipi-disco-soundwire
|
||||
|
||||
(publicly accessible with registration or directly accessible to MIPI
|
||||
members)
|
||||
|
||||
MIPI Alliance Manufacturer ID Page: mid.mipi.org
|
||||
@@ -667,27 +667,28 @@ Making the driver recognize the device
|
||||
Since the driver does not declare any device GUID's, it will not get
|
||||
loaded automatically and will not automatically bind to any devices, you
|
||||
must load it and allocate id to the driver yourself. For example, to use
|
||||
the network device GUID::
|
||||
the network device class GUID::
|
||||
|
||||
modprobe uio_hv_generic
|
||||
echo "f8615163-df3e-46c5-913f-f2d2f965ed0e" > /sys/bus/vmbus/drivers/uio_hv_generic/new_id
|
||||
|
||||
If there already is a hardware specific kernel driver for the device,
|
||||
the generic driver still won't bind to it, in this case if you want to
|
||||
use the generic driver (why would you?) you'll have to manually unbind
|
||||
the hardware specific driver and bind the generic driver, like this::
|
||||
use the generic driver for a userspace library you'll have to manually unbind
|
||||
the hardware specific driver and bind the generic driver, using the device specific GUID
|
||||
like this::
|
||||
|
||||
echo -n vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3 > /sys/bus/vmbus/drivers/hv_netvsc/unbind
|
||||
echo -n vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3 > /sys/bus/vmbus/drivers/uio_hv_generic/bind
|
||||
echo -n ed963694-e847-4b2a-85af-bc9cfc11d6f3 > /sys/bus/vmbus/drivers/hv_netvsc/unbind
|
||||
echo -n ed963694-e847-4b2a-85af-bc9cfc11d6f3 > /sys/bus/vmbus/drivers/uio_hv_generic/bind
|
||||
|
||||
You can verify that the device has been bound to the driver by looking
|
||||
for it in sysfs, for example like the following::
|
||||
|
||||
ls -l /sys/bus/vmbus/devices/vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver
|
||||
ls -l /sys/bus/vmbus/devices/ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver
|
||||
|
||||
Which if successful should print::
|
||||
|
||||
.../vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver -> ../../../bus/vmbus/drivers/uio_hv_generic
|
||||
.../ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver -> ../../../bus/vmbus/drivers/uio_hv_generic
|
||||
|
||||
Things to know about uio_hv_generic
|
||||
-----------------------------------
|
||||
@@ -697,6 +698,17 @@ prevents the device from generating further interrupts until the bit is
|
||||
cleared. The userspace driver should clear this bit before blocking and
|
||||
waiting for more interrupts.
|
||||
|
||||
When host rescinds a device, the interrupt file descriptor is marked down
|
||||
and any reads of the interrupt file descriptor will return -EIO. Similar
|
||||
to a closed socket or disconnected serial device.
|
||||
|
||||
The vmbus device regions are mapped into uio device resources:
|
||||
0) Channel ring buffers: guest to host and host to guest
|
||||
1) Guest to host interrupt signalling pages
|
||||
2) Guest to host monitor page
|
||||
3) Network receive buffer region
|
||||
4) Network send buffer region
|
||||
|
||||
Further information
|
||||
===================
|
||||
|
||||
|
||||
@@ -11,61 +11,65 @@ hidden away in a low level driver which registers a set of ops with the core.
|
||||
The FPGA image data itself is very manufacturer specific, but for our purposes
|
||||
it's just binary data. The FPGA manager core won't parse it.
|
||||
|
||||
The FPGA image to be programmed can be in a scatter gather list, a single
|
||||
contiguous buffer, or a firmware file. Because allocating contiguous kernel
|
||||
memory for the buffer should be avoided, users are encouraged to use a scatter
|
||||
gather list instead if possible.
|
||||
|
||||
The particulars for programming the image are presented in a structure (struct
|
||||
fpga_image_info). This struct contains parameters such as pointers to the
|
||||
FPGA image as well as image-specific particulars such as whether the image was
|
||||
built for full or partial reconfiguration.
|
||||
|
||||
API Functions:
|
||||
==============
|
||||
|
||||
To program the FPGA from a file or from a buffer:
|
||||
-------------------------------------------------
|
||||
To program the FPGA:
|
||||
--------------------
|
||||
|
||||
int fpga_mgr_buf_load(struct fpga_manager *mgr,
|
||||
struct fpga_image_info *info,
|
||||
const char *buf, size_t count);
|
||||
int fpga_mgr_load(struct fpga_manager *mgr,
|
||||
struct fpga_image_info *info);
|
||||
|
||||
Load the FPGA from an image which exists as a contiguous buffer in
|
||||
memory. Allocating contiguous kernel memory for the buffer should be avoided,
|
||||
users are encouraged to use the _sg interface instead of this.
|
||||
|
||||
int fpga_mgr_buf_load_sg(struct fpga_manager *mgr,
|
||||
struct fpga_image_info *info,
|
||||
struct sg_table *sgt);
|
||||
|
||||
Load the FPGA from an image from non-contiguous in memory. Callers can
|
||||
construct a sg_table using alloc_page backed memory.
|
||||
|
||||
int fpga_mgr_firmware_load(struct fpga_manager *mgr,
|
||||
struct fpga_image_info *info,
|
||||
const char *image_name);
|
||||
|
||||
Load the FPGA from an image which exists as a file. The image file must be on
|
||||
the firmware search path (see the firmware class documentation). If successful,
|
||||
Load the FPGA from an image which is indicated in the info. If successful,
|
||||
the FPGA ends up in operating mode. Return 0 on success or a negative error
|
||||
code.
|
||||
|
||||
A FPGA design contained in a FPGA image file will likely have particulars that
|
||||
affect how the image is programmed to the FPGA. These are contained in struct
|
||||
fpga_image_info. Currently the only such particular is a single flag bit
|
||||
indicating whether the image is for full or partial reconfiguration.
|
||||
To allocate or free a struct fpga_image_info:
|
||||
---------------------------------------------
|
||||
|
||||
struct fpga_image_info *fpga_image_info_alloc(struct device *dev);
|
||||
|
||||
void fpga_image_info_free(struct fpga_image_info *info);
|
||||
|
||||
To get/put a reference to a FPGA manager:
|
||||
-----------------------------------------
|
||||
|
||||
struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
|
||||
struct fpga_manager *fpga_mgr_get(struct device *dev);
|
||||
|
||||
Given a DT node or device, get an exclusive reference to a FPGA manager.
|
||||
|
||||
void fpga_mgr_put(struct fpga_manager *mgr);
|
||||
|
||||
Release the reference.
|
||||
Given a DT node or device, get a reference to a FPGA manager. This pointer
|
||||
can be saved until you are ready to program the FPGA. fpga_mgr_put releases
|
||||
the reference.
|
||||
|
||||
|
||||
To get exclusive control of a FPGA manager:
|
||||
-------------------------------------------
|
||||
|
||||
int fpga_mgr_lock(struct fpga_manager *mgr);
|
||||
void fpga_mgr_unlock(struct fpga_manager *mgr);
|
||||
|
||||
The user should call fpga_mgr_lock and verify that it returns 0 before
|
||||
attempting to program the FPGA. Likewise, the user should call
|
||||
fpga_mgr_unlock when done programming the FPGA.
|
||||
|
||||
|
||||
To register or unregister the low level FPGA-specific driver:
|
||||
-------------------------------------------------------------
|
||||
|
||||
int fpga_mgr_register(struct device *dev, const char *name,
|
||||
const struct fpga_manager_ops *mops,
|
||||
void *priv);
|
||||
const struct fpga_manager_ops *mops,
|
||||
void *priv);
|
||||
|
||||
void fpga_mgr_unregister(struct device *dev);
|
||||
|
||||
@@ -75,62 +79,58 @@ device."
|
||||
|
||||
How to write an image buffer to a supported FPGA
|
||||
================================================
|
||||
/* Include to get the API */
|
||||
#include <linux/fpga/fpga-mgr.h>
|
||||
|
||||
/* device node that specifies the FPGA manager to use */
|
||||
struct device_node *mgr_node = ...
|
||||
|
||||
/* FPGA image is in this buffer. count is size of the buffer. */
|
||||
char *buf = ...
|
||||
int count = ...
|
||||
|
||||
/* struct with information about the FPGA image to program. */
|
||||
struct fpga_image_info info;
|
||||
|
||||
/* flags indicates whether to do full or partial reconfiguration */
|
||||
info.flags = 0;
|
||||
|
||||
struct fpga_manager *mgr;
|
||||
struct fpga_image_info *info;
|
||||
int ret;
|
||||
|
||||
/*
|
||||
* Get a reference to FPGA manager. The manager is not locked, so you can
|
||||
* hold onto this reference without it preventing programming.
|
||||
*
|
||||
* This example uses the device node of the manager. Alternatively, use
|
||||
* fpga_mgr_get(dev) instead if you have the device.
|
||||
*/
|
||||
mgr = of_fpga_mgr_get(mgr_node);
|
||||
|
||||
/* struct with information about the FPGA image to program. */
|
||||
info = fpga_image_info_alloc(dev);
|
||||
|
||||
/* flags indicates whether to do full or partial reconfiguration */
|
||||
info->flags = FPGA_MGR_PARTIAL_RECONFIG;
|
||||
|
||||
/*
|
||||
* At this point, indicate where the image is. This is pseudo-code; you're
|
||||
* going to use one of these three.
|
||||
*/
|
||||
if (image is in a scatter gather table) {
|
||||
|
||||
info->sgt = [your scatter gather table]
|
||||
|
||||
} else if (image is in a buffer) {
|
||||
|
||||
info->buf = [your image buffer]
|
||||
info->count = [image buffer size]
|
||||
|
||||
} else if (image is in a firmware file) {
|
||||
|
||||
info->firmware_name = devm_kstrdup(dev, firmware_name, GFP_KERNEL);
|
||||
|
||||
}
|
||||
|
||||
/* Get exclusive control of FPGA manager */
|
||||
struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
|
||||
ret = fpga_mgr_lock(mgr);
|
||||
|
||||
/* Load the buffer to the FPGA */
|
||||
ret = fpga_mgr_buf_load(mgr, &info, buf, count);
|
||||
|
||||
/* Release the FPGA manager */
|
||||
fpga_mgr_unlock(mgr);
|
||||
fpga_mgr_put(mgr);
|
||||
|
||||
|
||||
How to write an image file to a supported FPGA
|
||||
==============================================
|
||||
/* Include to get the API */
|
||||
#include <linux/fpga/fpga-mgr.h>
|
||||
|
||||
/* device node that specifies the FPGA manager to use */
|
||||
struct device_node *mgr_node = ...
|
||||
|
||||
/* FPGA image is in this file which is in the firmware search path */
|
||||
const char *path = "fpga-image-9.rbf"
|
||||
|
||||
/* struct with information about the FPGA image to program. */
|
||||
struct fpga_image_info info;
|
||||
|
||||
/* flags indicates whether to do full or partial reconfiguration */
|
||||
info.flags = 0;
|
||||
|
||||
int ret;
|
||||
|
||||
/* Get exclusive control of FPGA manager */
|
||||
struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
|
||||
|
||||
/* Get the firmware image (path) and load it to the FPGA */
|
||||
ret = fpga_mgr_firmware_load(mgr, &info, path);
|
||||
|
||||
/* Release the FPGA manager */
|
||||
fpga_mgr_put(mgr);
|
||||
|
||||
/* Deallocate the image info if you're done with it */
|
||||
fpga_image_info_free(info);
|
||||
|
||||
How to support a new FPGA device
|
||||
================================
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
FPGA Regions
|
||||
|
||||
Alan Tull 2017
|
||||
|
||||
CONTENTS
|
||||
- Introduction
|
||||
- The FPGA region API
|
||||
- Usage example
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
This document is meant to be an brief overview of the FPGA region API usage. A
|
||||
more conceptual look at regions can be found in [1].
|
||||
|
||||
For the purposes of this API document, let's just say that a region associates
|
||||
an FPGA Manager and a bridge (or bridges) with a reprogrammable region of an
|
||||
FPGA or the whole FPGA. The API provides a way to register a region and to
|
||||
program a region.
|
||||
|
||||
Currently the only layer above fpga-region.c in the kernel is the Device Tree
|
||||
support (of-fpga-region.c) described in [1]. The DT support layer uses regions
|
||||
to program the FPGA and then DT to handle enumeration. The common region code
|
||||
is intended to be used by other schemes that have other ways of accomplishing
|
||||
enumeration after programming.
|
||||
|
||||
An fpga-region can be set up to know the following things:
|
||||
* which FPGA manager to use to do the programming
|
||||
* which bridges to disable before programming and enable afterwards.
|
||||
|
||||
Additional info needed to program the FPGA image is passed in the struct
|
||||
fpga_image_info [2] including:
|
||||
* pointers to the image as either a scatter-gather buffer, a contiguous
|
||||
buffer, or the name of firmware file
|
||||
* flags indicating specifics such as whether the image if for partial
|
||||
reconfiguration.
|
||||
|
||||
===================
|
||||
The FPGA region API
|
||||
===================
|
||||
|
||||
To register or unregister a region:
|
||||
-----------------------------------
|
||||
|
||||
int fpga_region_register(struct device *dev,
|
||||
struct fpga_region *region);
|
||||
int fpga_region_unregister(struct fpga_region *region);
|
||||
|
||||
An example of usage can be seen in the probe function of [3]
|
||||
|
||||
To program an FPGA:
|
||||
-------------------
|
||||
int fpga_region_program_fpga(struct fpga_region *region);
|
||||
|
||||
This function operates on info passed in the fpga_image_info
|
||||
(region->info).
|
||||
|
||||
This function will attempt to:
|
||||
* lock the region's mutex
|
||||
* lock the region's FPGA manager
|
||||
* build a list of FPGA bridges if a method has been specified to do so
|
||||
* disable the bridges
|
||||
* program the FPGA
|
||||
* re-enable the bridges
|
||||
* release the locks
|
||||
|
||||
=============
|
||||
Usage example
|
||||
=============
|
||||
|
||||
First, allocate the info struct:
|
||||
|
||||
info = fpga_image_info_alloc(dev);
|
||||
if (!info)
|
||||
return -ENOMEM;
|
||||
|
||||
Set flags as needed, i.e.
|
||||
|
||||
info->flags |= FPGA_MGR_PARTIAL_RECONFIG;
|
||||
|
||||
Point to your FPGA image, such as:
|
||||
|
||||
info->sgt = &sgt;
|
||||
|
||||
Add info to region and do the programming:
|
||||
|
||||
region->info = info;
|
||||
ret = fpga_region_program_fpga(region);
|
||||
|
||||
Then enumerate whatever hardware has appeared in the FPGA.
|
||||
|
||||
--
|
||||
[1] ../devicetree/bindings/fpga/fpga-region.txt
|
||||
[2] ./fpga-mgr.txt
|
||||
[3] ../../drivers/fpga/of-fpga-region.c
|
||||
@@ -0,0 +1,23 @@
|
||||
Linux kernel FPGA support
|
||||
|
||||
Alan Tull 2017
|
||||
|
||||
The main point of this project has been to separate the out the upper layers
|
||||
that know when to reprogram a FPGA from the lower layers that know how to
|
||||
reprogram a specific FPGA device. The intention is to make this manufacturer
|
||||
agnostic, understanding that of course the FPGA images are very device specific
|
||||
themselves.
|
||||
|
||||
The framework in the kernel includes:
|
||||
* low level FPGA manager drivers that know how to program a specific device
|
||||
* the fpga-mgr framework they are registered with
|
||||
* low level FPGA bridge drivers for hard/soft bridges which are intended to
|
||||
be disable during FPGA programming
|
||||
* the fpga-bridge framework they are registered with
|
||||
* the fpga-region framework which associates and controls managers and bridges
|
||||
as reconfigurable regions
|
||||
* the of-fpga-region support for reprogramming FPGAs when device tree overlays
|
||||
are applied.
|
||||
|
||||
I would encourage you the user to add code that creates FPGA regions rather
|
||||
that trying to control managers and bridges separately.
|
||||
+36
-2
@@ -3421,8 +3421,8 @@ M: Arnd Bergmann <arnd@arndb.de>
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
|
||||
S: Supported
|
||||
F: drivers/char/*
|
||||
F: drivers/misc/*
|
||||
F: drivers/char/
|
||||
F: drivers/misc/
|
||||
F: include/linux/miscdevice.h
|
||||
|
||||
CHECKPATCH
|
||||
@@ -12526,6 +12526,13 @@ F: lib/siphash.c
|
||||
F: lib/test_siphash.c
|
||||
F: include/linux/siphash.h
|
||||
|
||||
SIOX
|
||||
M: Gavin Schenk <g.schenk@eckelmann.de>
|
||||
M: Uwe Kleine-König <kernel@pengutronix.de>
|
||||
S: Supported
|
||||
F: drivers/siox/*
|
||||
F: include/trace/events/siox.h
|
||||
|
||||
SIS 190 ETHERNET DRIVER
|
||||
M: Francois Romieu <romieu@fr.zoreil.com>
|
||||
L: netdev@vger.kernel.org
|
||||
@@ -12577,6 +12584,14 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
|
||||
F: include/linux/srcu.h
|
||||
F: kernel/rcu/srcu.c
|
||||
|
||||
SERIAL LOW-POWER INTER-CHIP MEDIA BUS (SLIMbus)
|
||||
M: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/slimbus/
|
||||
F: Documentation/devicetree/bindings/slimbus/
|
||||
F: include/linux/slimbus.h
|
||||
|
||||
SMACK SECURITY MODULE
|
||||
M: Casey Schaufler <casey@schaufler-ca.com>
|
||||
L: linux-security-module@vger.kernel.org
|
||||
@@ -12802,6 +12817,16 @@ F: Documentation/sound/alsa/soc/
|
||||
F: sound/soc/
|
||||
F: include/sound/soc*
|
||||
|
||||
SOUNDWIRE SUBSYSTEM
|
||||
M: Vinod Koul <vinod.koul@intel.com>
|
||||
M: Sanyog Kale <sanyog.r.kale@intel.com>
|
||||
R: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
F: Documentation/driver-api/soundwire/
|
||||
F: drivers/soundwire/
|
||||
F: include/linux/soundwire/
|
||||
|
||||
SP2 MEDIA DRIVER
|
||||
M: Olli Salonen <olli.salonen@iki.fi>
|
||||
L: linux-media@vger.kernel.org
|
||||
@@ -14672,6 +14697,15 @@ S: Maintained
|
||||
F: drivers/virtio/virtio_input.c
|
||||
F: include/uapi/linux/virtio_input.h
|
||||
|
||||
VIRTUAL BOX GUEST DEVICE DRIVER
|
||||
M: Hans de Goede <hdegoede@redhat.com>
|
||||
M: Arnd Bergmann <arnd@arndb.de>
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
S: Maintained
|
||||
F: include/linux/vbox_utils.h
|
||||
F: include/uapi/linux/vbox*.h
|
||||
F: drivers/virt/vboxguest/
|
||||
|
||||
VIRTUAL SERIO DEVICE DRIVER
|
||||
M: Stephen Chandler Paul <thatslyude@gmail.com>
|
||||
S: Maintained
|
||||
|
||||
@@ -239,17 +239,24 @@ void hyperv_report_panic(struct pt_regs *regs, long err)
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(hyperv_report_panic);
|
||||
|
||||
bool hv_is_hypercall_page_setup(void)
|
||||
bool hv_is_hyperv_initialized(void)
|
||||
{
|
||||
union hv_x64_msr_hypercall_contents hypercall_msr;
|
||||
|
||||
/* Check if the hypercall page is setup */
|
||||
/*
|
||||
* Ensure that we're really on Hyper-V, and not a KVM or Xen
|
||||
* emulation of Hyper-V
|
||||
*/
|
||||
if (x86_hyper_type != X86_HYPER_MS_HYPERV)
|
||||
return false;
|
||||
|
||||
/*
|
||||
* Verify that earlier initialization succeeded by checking
|
||||
* that the hypercall page is setup
|
||||
*/
|
||||
hypercall_msr.as_uint64 = 0;
|
||||
rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
|
||||
|
||||
if (!hypercall_msr.enable)
|
||||
return false;
|
||||
|
||||
return true;
|
||||
return hypercall_msr.enable;
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(hv_is_hypercall_page_setup);
|
||||
EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
|
||||
|
||||
@@ -314,11 +314,11 @@ void hyperv_init(void);
|
||||
void hyperv_setup_mmu_ops(void);
|
||||
void hyper_alloc_mmu(void);
|
||||
void hyperv_report_panic(struct pt_regs *regs, long err);
|
||||
bool hv_is_hypercall_page_setup(void);
|
||||
bool hv_is_hyperv_initialized(void);
|
||||
void hyperv_cleanup(void);
|
||||
#else /* CONFIG_HYPERV */
|
||||
static inline void hyperv_init(void) {}
|
||||
static inline bool hv_is_hypercall_page_setup(void) { return false; }
|
||||
static inline bool hv_is_hyperv_initialized(void) { return false; }
|
||||
static inline void hyperv_cleanup(void) {}
|
||||
static inline void hyperv_setup_mmu_ops(void) {}
|
||||
#endif /* CONFIG_HYPERV */
|
||||
|
||||
@@ -153,6 +153,8 @@ source "drivers/remoteproc/Kconfig"
|
||||
|
||||
source "drivers/rpmsg/Kconfig"
|
||||
|
||||
source "drivers/soundwire/Kconfig"
|
||||
|
||||
source "drivers/soc/Kconfig"
|
||||
|
||||
source "drivers/devfreq/Kconfig"
|
||||
@@ -213,4 +215,8 @@ source "drivers/opp/Kconfig"
|
||||
|
||||
source "drivers/visorbus/Kconfig"
|
||||
|
||||
source "drivers/siox/Kconfig"
|
||||
|
||||
source "drivers/slimbus/Kconfig"
|
||||
|
||||
endmenu
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user