133 lines · plain
1============================2Linux kernel SLIMbus support3============================4 5Overview6========7 8What is SLIMbus?9----------------10SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by11MIPI (Mobile Industry Processor Interface) alliance. The bus uses master/slave12configuration, and is a 2-wire multi-drop implementation (clock, and data).13 14Currently, SLIMbus is used to interface between application processors of SoCs15(System-on-Chip) and peripheral components (typically codec). SLIMbus uses16Time-Division-Multiplexing to accommodate multiple data channels, and17a control channel.18 19The control channel is used for various control functions such as bus20management, configuration and status updates. These messages can be unicast (e.g.21reading/writing device specific values), or multicast (e.g. data channel22reconfiguration sequence is a broadcast message announced to all devices)23 24A data channel is used for data-transfer between 2 SLIMbus devices. Data25channel uses dedicated ports on the device.26 27Hardware description:28---------------------29SLIMbus specification has different types of device classifications based on30their capabilities.31A manager device is responsible for enumeration, configuration, and dynamic32channel allocation. Every bus has 1 active manager.33 34A generic device is a device providing application functionality (e.g. codec).35 36Framer device is responsible for clocking the bus, and transmitting frame-sync37and framing information on the bus.38 39Each SLIMbus component has an interface device for monitoring physical layer.40 41Typically each SoC contains SLIMbus component having 1 manager, 1 framer device,421 generic device (for data channel support), and 1 interface device.43External peripheral SLIMbus component usually has 1 generic device (for44functionality/data channel support), and an associated interface device.45The generic device's registers are mapped as 'value elements' so that they can46be written/read using SLIMbus control channel exchanging control/status type of47information.48In case there are multiple framer devices on the same bus, manager device is49responsible to select the active-framer for clocking the bus.50 51Per specification, SLIMbus uses "clock gears" to do power management based on52current frequency and bandwidth requirements. There are 10 clock gears and each53gear changes the SLIMbus frequency to be twice its previous gear.54 55Each device has a 6-byte enumeration-address and the manager assigns every56device with a 1-byte logical address after the devices report presence on the57bus.58 59Software description:60---------------------61There are 2 types of SLIMbus drivers:62 63slim_controller represents a 'controller' for SLIMbus. This driver should64implement duties needed by the SoC (manager device, associated65interface device for monitoring the layers and reporting errors, default66framer device).67 68slim_device represents the 'generic device/component' for SLIMbus, and a69slim_driver should implement driver for that slim_device.70 71Device notifications to the driver:72-----------------------------------73Since SLIMbus devices have mechanisms for reporting their presence, the74framework allows drivers to bind when corresponding devices report their75presence on the bus.76However, it is possible that the driver needs to be probed77first so that it can enable corresponding SLIMbus device (e.g. power it up and/or78take it out of reset). To support that behavior, the framework allows drivers79to probe first as well (e.g. using standard DeviceTree compatibility field).80This creates the necessity for the driver to know when the device is functional81(i.e. reported present). device_up callback is used for that reason when the82device reports present and is assigned a logical address by the controller.83 84Similarly, SLIMbus devices 'report absent' when they go down. A 'device_down'85callback notifies the driver when the device reports absent and its logical86address assignment is invalidated by the controller.87 88Another notification "boot_device" is used to notify the slim_driver when89controller resets the bus. This notification allows the driver to take necessary90steps to boot the device so that it's functional after the bus has been reset.91 92Driver and Controller APIs:93---------------------------94.. kernel-doc:: include/linux/slimbus.h95 :internal:96 97.. kernel-doc:: drivers/slimbus/slimbus.h98 :internal:99 100.. kernel-doc:: drivers/slimbus/core.c101 :export:102 103Clock-pause:104------------105SLIMbus mandates that a reconfiguration sequence (known as clock-pause) be106broadcast to all active devices on the bus before the bus can enter low-power107mode. Controller uses this sequence when it decides to enter low-power mode so108that corresponding clocks and/or power-rails can be turned off to save power.109Clock-pause is exited by waking up framer device (if controller driver initiates110exiting low power mode), or by toggling the data line (if a slave device wants111to initiate it).112 113Clock-pause APIs:114~~~~~~~~~~~~~~~~~115.. kernel-doc:: drivers/slimbus/sched.c116 :export:117 118Messaging:119----------120The framework supports regmap and read/write apis to exchange control-information121with a SLIMbus device. APIs can be synchronous or asynchronous.122The header file <linux/slimbus.h> has more documentation about messaging APIs.123 124Messaging APIs:125~~~~~~~~~~~~~~~126.. kernel-doc:: drivers/slimbus/messaging.c127 :export:128 129Streaming APIs:130~~~~~~~~~~~~~~~131.. kernel-doc:: drivers/slimbus/stream.c132 :export:133