Lines Matching refs:FW

96 	| ISH Hardware/Firmware(FW) |
118 3.2.1 IPC/FW message types
129 internal queues to sequence messages and send them in order to the FW.
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
181 the link will be dropped if major FW reset occurs.
190 Each side (host and FW) manages its DMA transfer memory independently. When an
191 ISHTP client from either host or FW side wants to send something, it decides
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.
201 if thw host doesn't support DMA, then it won't send DMA allocation, so FW can't
202 send DMA; if FW doesn't support DMA then it won't respond with
205 it's request to do host->ISH DMA transfer; when FW sends DMA_XFER, it means
210 FW), DMA_XFER transfers ownership on the region that contains ISHTP message to
216 Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC
226 bus message protocol. These buffers are required because the FW may have not
233 The host enumeration bus command allow discovery of clients present in the FW.
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,
261 - enumerate HID devices under FW ISH client