Lines Matching full:slave

25 The SoundWire protocol supports up to eleven Slave interfaces. All the
36 two Slave devices. ::
40         |    Master     |-------+-------------------------------|    Slave      |
49                              |   Slave     |
59 or Slave interface, which of course can be confusing. In this summary and
61 Linux device model by mapping each Slave interface connected on the bus as a
63 a framework to implement a SoundWire Slave driver with an API allowing
69 Programs all the MIPI-defined Slave registers. Represents a SoundWire
72 Slave:
73 Registers as SoundWire Slave device (Linux Device). Multiple Slave devices
76 Slave driver:
77 Driver controlling the Slave device. MIPI-specified registers are controlled
79 Any implementation-defined Slave register is controlled by Slave driver. In
80 practice, it is expected that the Slave driver relies on regmap and does not
87 implementation and SoundWire Slave devices. All the code uses the "sdw"
112 		/* Check ACPI for Slave devices */
115 		/* Check DT for Slave devices */
137 Programming interfaces (SoundWire Slave Driver)
140 The MIPI specification requires each Slave interface to expose a unique
144 currently unused. Slave driver is written for a specific vendor and part
145 identifier, Bus enumerates the Slave device based on these two ids.
146 Slave device and driver match is done based on these two ids . Probe
147 of the Slave driver is called by Bus on successful match between device and
148 driver id. A parent/child relationship is enforced between Master and Slave
152 The information on Master/Slave dependencies is stored in platform data,
180 For capabilities, Bus implements API to read standard Slave MIPI properties
181 and also provides callback in Slave ops for Slave driver to implement own
183 Slave capabilities to program Slave registers and to control the Bus