Lines Matching +full:rx +full:- +full:queues +full:- +full:to +full:- +full:use
5 A sensor hub enables the ability to offload sensor polling and algorithm
6 processing to a dedicated low power co-processor. This allows the core
7 processor to go into low power modes more often, resulting in the increased
10 There are many vendors providing external sensor hubs confirming to HID
17 These ISH also comply to HID sensor specification, but the difference is the
19 mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB.
27 ----------------- ----------------------
28 | USB HID | --> | ISH HID |
29 ----------------- ----------------------
30 ----------------- ----------------------
31 | USB protocol | --> | ISH Transport |
32 ----------------- ----------------------
33 ----------------- ----------------------
34 | EHCI/XHCI | --> | ISH IPC |
35 ----------------- ----------------------
37 ----------------- ----------------------
38 |Host controller| --> | ISH processor |
39 ----------------- ----------------------
41 ----------------- ----------------------
42 | USB End points| --> | ISH Clients |
43 ----------------- ----------------------
47 very light weight tailored to manage and communicate with ISH client
51 firmware. Like USB endpoints the messaging can be to/from a client. As part of
66 ---------------------------
68 ---------------------------
70 ----------------IIO ABI----------------
71 --------------------------
73 --------------------------
74 --------------------------
76 --------------------------
77 --------------------------
79 --------------------------
80 --------------------------
82 --------------------------
83 --------------------------
85 --------------------------
86 --------------------------
88 --------------------------
89 --------------------------
91 --------------------------
93 ---------------- PCI -----------------
95 ----------------------------
97 ----------------------------
103 ----------------------
105 The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI
107 the source code which enumerate drivers needs to update from generation to
111 ----------------------------------------------
113 Location: drivers/hid/intel-ish-hid/ipc
116 hw-ish-regs.h.
122 are to and from transport layers.
124 TX and RX of Transport messages
128 RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains
129 internal queues to sequence messages and send them in order to the FW.
130 Optionally the caller can register handler to get notification of completion.
131 A door bell mechanism is used in messaging to trigger processing in host and
133 doorbell register is used by host drivers to determine that the interrupt
136 Each side has 32 32-bit message registers and a 32-bit doorbell. Doorbell
141 Bit 31: doorbell trigger (signal H/W interrupt to the other side)
147 To abstract HW level IPC communication, a set of callbacks are registered.
148 The transport layer uses them to send and receive messages.
149 Refer to struct ishtp_hw_ops for callbacks.
152 -----------------------
154 Location: drivers/hid/intel-ish-hid/ishtp/
159 The transport layer is a bi-directional protocol, which defines:
160 - Set of commands to start, stop, connect, disconnect and flow control
162 - A flow control mechanism to avoid buffer overflows
165 http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
166 specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer"
171 Each FW client and a protocol is identified by an UUID. In order to communicate
172 to a FW client, a connection must be established using connect request and
178 flow-control credit before. Once it sent a message, it may not send another one
180 Either side can send disconnect request bus message to end communication. Also
183 3.3.3 Peer to Peer data transfer
186 Peer to Peer data transfer can happen with or without using DMA. Depending on
191 ISHTP client from either host or FW side wants to send something, it decides
192 whether to send over IPC or over DMA; for each transfer the decision is
194 the respective host buffer (TX when host client sends, RX when FW client
199 (that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK.
200 Additionally to DMA address communication, this sequence checks capabilities:
203 DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers.
205 it's request to do host->ISH DMA transfer; when FW sends DMA_XFER, it means
209 At initial state all outgoing memory belongs to the sender (TX to host, RX to
210 FW), DMA_XFER transfers ownership on the region that contains ISHTP message to
211 the receiving side, DMA_XFER_ACK returns ownership to the sender. A sender
212 needs not wait for previous DMA_XFER to be ack'ed, and may send another message
215 (up to IPC MTU), thus allowing for interrupt throttling.
216 Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC
222 When a client initiate a connection, a ring or RX and TX buffers are allocated.
224 TX and RX buffers respectively. On send request from client, the data to be
225 sent is copied to one of the send ring buffer and scheduled to be sent using
228 to send. Same thing holds true on receive side and flow control is required.
236 To ease in implantation and allow independent driver handle each client
242 - Host sends HOST_START_REQ_CMD, indicating that host ISHTP layer is up.
243 - FW responds with HOST_START_RES_CMD
244 - Host sends HOST_ENUM_REQ_CMD (enumerate FW clients)
245 - FW responds with HOST_ENUM_RES_CMD that includes bitmap of available FW
247 - For each FW ID found in that bitmap host sends
249 - FW responds with HOST_CLIENT_PROPERTIES_RES_CMD. Properties include UUID,
251 - Once host received properties for that last discovered client, it considers
255 -----------------------
257 Location: drivers/hid/intel-ish-hid
261 - enumerate HID devices under FW ISH client
262 - Get Report descriptor
263 - Register with HID core as a LL driver
264 - Process Get/Set feature request
265 - Get input reports
268 ---------------------------------------------
271 Refer to
272 Documentation/hid/hid-sensor.rst for HID sensor
273 Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space
275 3.6 End to End HID transport Sequence Diagram
276 ---------------------------------------------
280 HID-ISH-CLN ISHTP IPC HW
282 | | |-----WAKE UP------------------>|
284 | | |-----HOST READY--------------->|
286 | | |<----MNG_RESET_NOTIFY_ACK----- |
288 | |<----ISHTP_START------ | |
290 | |<-----------------HOST_START_RES_CMD-------------------|
292 | |------------------QUERY_SUBSCRIBER-------------------->|
294 | |------------------HOST_ENUM_REQ_CMD------------------->|
296 | |<-----------------HOST_ENUM_RES_CMD--------------------|
298 | |------------------HOST_CLIENT_PROPERTIES_REQ_CMD------>|
300 | |<-----------------HOST_CLIENT_PROPERTIES_RES_CMD-------|
303 | |------------------HOST_CLIENT_PROPERTIES_REQ_CMD------>|
305 | |<-----------------HOST_CLIENT_PROPERTIES_RES_CMD-------|
308 | |--Repeat HOST_CLIENT_PROPERTIES_REQ_CMD-till last one--|
311 |----ishtp_cl_connect--->|----------------- CLIENT_CONNECT_REQ_CMD-------------->|
313 | |<----------------CLIENT_CONNECT_RES_CMD----------------|
318 HOSTIF_DM_ENUM_DEVICES) |----------fill ishtp_msg_hdr struct write to HW----- >|
320 | | |<-----IRQ(IPC_PROTOCOL_ISHTP---|
322 |<--ENUM_DEVICE RSP------| | |
326 HOSTIF_GET_HID_DESCRIPTOR|----------fill ishtp_msg_hdr struct write to HW----- >|
332 HOSTIF_GET_REPORT_DESCRIPTOR|--------------fill ishtp_msg_hdr struct write to HW-- >|
342 -----------------
344 To debug ISH, event tracing mechanism is used. To enable debug logs
349 -----------------------------------------------------
353 root@otcpl-ThinkPad-Yoga-260:~# tree -l /sys/bus/iio/devices/
355 ├── iio:device0 -> ../../../devices/0044:8086:22D8.0001/HID-SENSOR-200073.9.auto/iio:device0