diff options
author | Eric Lapuyade <eric.lapuyade@intel.com> | 2012-05-07 06:31:17 -0400 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2012-05-15 17:28:01 -0400 |
commit | a202abb1ee98ee28faaca460bbbf684d05e94310 (patch) | |
tree | 90349d7b1b528bede1f49be97b91f239a0e6ddd1 | |
parent | 1676f75159c8091e865c33b61ad4934dfd3b7821 (diff) |
NFC: Update Documentation/nfc-hci.txt
Document the new HCI ops and fix a few typos and spelling mistakes.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-rw-r--r-- | Documentation/nfc/nfc-hci.txt | 45 |
1 files changed, 35 insertions, 10 deletions
diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt index 216b7254fcc3..320f9336c781 100644 --- a/Documentation/nfc/nfc-hci.txt +++ b/Documentation/nfc/nfc-hci.txt | |||
@@ -22,9 +22,9 @@ response to arrive. | |||
22 | HCI events can also be received from the host controller. They will be handled | 22 | HCI events can also be received from the host controller. They will be handled |
23 | and a translation will be forwarded to NFC Core as needed. | 23 | and a translation will be forwarded to NFC Core as needed. |
24 | HCI uses 2 execution contexts: | 24 | HCI uses 2 execution contexts: |
25 | - one if for executing commands : nfc_hci_msg_tx_work(). Only one command | 25 | - one for executing commands : nfc_hci_msg_tx_work(). Only one command |
26 | can be executing at any given moment. | 26 | can be executing at any given moment. |
27 | - one if for dispatching received events and responses : nfc_hci_msg_rx_work() | 27 | - one for dispatching received events and commands : nfc_hci_msg_rx_work(). |
28 | 28 | ||
29 | HCI Session initialization: | 29 | HCI Session initialization: |
30 | --------------------------- | 30 | --------------------------- |
@@ -52,18 +52,42 @@ entry points: | |||
52 | struct nfc_hci_ops { | 52 | struct nfc_hci_ops { |
53 | int (*open)(struct nfc_hci_dev *hdev); | 53 | int (*open)(struct nfc_hci_dev *hdev); |
54 | void (*close)(struct nfc_hci_dev *hdev); | 54 | void (*close)(struct nfc_hci_dev *hdev); |
55 | int (*hci_ready) (struct nfc_hci_dev *hdev); | ||
55 | int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb); | 56 | int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb); |
56 | int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols); | 57 | int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols); |
57 | int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate, | 58 | int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate, |
58 | struct nfc_target *target); | 59 | struct nfc_target *target); |
60 | int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate, | ||
61 | struct nfc_target *target); | ||
62 | int (*data_exchange) (struct nfc_hci_dev *hdev, | ||
63 | struct nfc_target *target, | ||
64 | struct sk_buff *skb, struct sk_buff **res_skb); | ||
65 | int (*check_presence)(struct nfc_hci_dev *hdev, | ||
66 | struct nfc_target *target); | ||
59 | }; | 67 | }; |
60 | 68 | ||
61 | open() and close() shall turn the hardware on and off. xmit() shall simply | 69 | - open() and close() shall turn the hardware on and off. |
62 | write a frame to the chip. start_poll() is an optional entrypoint that shall | 70 | - hci_ready() is an optional entry point that is called right after the hci |
63 | set the hardware in polling mode. This must be implemented only if the hardware | 71 | session has been set up. The driver can use it to do additional initialization |
64 | uses proprietary gates or a mechanism slightly different from the HCI standard. | 72 | that must be performed using HCI commands. |
65 | target_from_gate() is another optional entrypoint to return the protocols | 73 | - xmit() shall simply write a frame to the chip. |
74 | - start_poll() is an optional entrypoint that shall set the hardware in polling | ||
75 | mode. This must be implemented only if the hardware uses proprietary gates or a | ||
76 | mechanism slightly different from the HCI standard. | ||
77 | - target_from_gate() is an optional entrypoint to return the nfc protocols | ||
66 | corresponding to a proprietary gate. | 78 | corresponding to a proprietary gate. |
79 | - complete_target_discovered() is an optional entry point to let the driver | ||
80 | perform additional proprietary processing necessary to auto activate the | ||
81 | discovered target. | ||
82 | - data_exchange() must be implemented by the driver if proprietary HCI commands | ||
83 | are required to send data to the tag. Some tag types will require custom | ||
84 | commands, others can be written to using the standard HCI commands. The driver | ||
85 | can check the tag type and either do proprietary processing, or return 1 to ask | ||
86 | for standard processing. | ||
87 | - check_presence() is an optional entry point that will be called regularly | ||
88 | by the core to check that an activated tag is still in the field. If this is | ||
89 | not implemented, the core will not be able to push tag_lost events to the user | ||
90 | space | ||
67 | 91 | ||
68 | On the rx path, the driver is responsible to push incoming HCP frames to HCI | 92 | On the rx path, the driver is responsible to push incoming HCP frames to HCI |
69 | using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling | 93 | using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling |
@@ -99,7 +123,8 @@ fast, cannot sleep. stores incoming frames into an shdlc rx queue | |||
99 | handles shdlc rx & tx queues. Dispatches HCI cmd responses. | 123 | handles shdlc rx & tx queues. Dispatches HCI cmd responses. |
100 | 124 | ||
101 | - HCI Tx Cmd worker (MSGTXWQ) | 125 | - HCI Tx Cmd worker (MSGTXWQ) |
102 | Serialize execution of HCI commands. Complete execution in case of resp timeout. | 126 | Serializes execution of HCI commands. Completes execution in case of response |
127 | timeout. | ||
103 | 128 | ||
104 | - HCI Rx worker (MSGRXWQ) | 129 | - HCI Rx worker (MSGRXWQ) |
105 | Dispatches incoming HCI commands or events. | 130 | Dispatches incoming HCI commands or events. |
@@ -133,11 +158,11 @@ able to complete the command with a timeout error if no response arrive. | |||
133 | SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function | 158 | SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function |
134 | handles shdlc framing in and out. It uses the driver xmit to send frames and | 159 | handles shdlc framing in and out. It uses the driver xmit to send frames and |
135 | receives incoming frames in an skb queue filled from the driver IRQ handler. | 160 | receives incoming frames in an skb queue filled from the driver IRQ handler. |
136 | SHDLC I(nformation) frames payload are HCP fragments. They are agregated to | 161 | SHDLC I(nformation) frames payload are HCP fragments. They are aggregated to |
137 | form complete HCI frames, which can be a response, command, or event. | 162 | form complete HCI frames, which can be a response, command, or event. |
138 | 163 | ||
139 | HCI Responses are dispatched immediately from this context to unblock | 164 | HCI Responses are dispatched immediately from this context to unblock |
140 | waiting command execution. Reponse processing involves invoking the completion | 165 | waiting command execution. Response processing involves invoking the completion |
141 | callback that was provided by nfc_hci_msg_tx_work() when it sent the command. | 166 | callback that was provided by nfc_hci_msg_tx_work() when it sent the command. |
142 | The completion callback will then wake the syscall context. | 167 | The completion callback will then wake the syscall context. |
143 | 168 | ||