Bryan Huntsman | 3f2bc4d | 2011-08-16 17:27:22 -0700 | [diff] [blame] | 1 | Introduction: |
| 2 | ============= |
| 3 | |
| 4 | The Qualcomm crypto engine (qce) driver is a module that |
| 5 | provides common services for accessing the Qualcomm crypto device. |
| 6 | Currently, the two main clients of qce are |
| 7 | -qcrypto driver (module provided for accessing CE HW by kernel space apps) |
| 8 | -qcedev driver (module provided for accessing CE HW by user space apps) |
| 9 | |
| 10 | |
| 11 | The crypto engine (qce) driver is a client to the DMA driver for the Qualcomm |
| 12 | DMA device - Application Data Mover (ADM). ADM is used to provide the DMA |
| 13 | transfer capability between Qualcomm crypto device hardware and DDR memory |
| 14 | for crypto operations. |
| 15 | |
| 16 | Figure 1. |
| 17 | --------- |
| 18 | |
| 19 | Linux kernel |
| 20 | (ex:IPSec)<--*Qualcomm crypto driver----+ |
| 21 | (qcrypto) | |
| 22 | (for kernel space app) | |
| 23 | | |
| 24 | +-->| |
| 25 | | |
| 26 | | *qce <----> Qualcomm |
| 27 | | driver ADM driver <---> ADM HW |
| 28 | +-->| | | |
| 29 | | | | |
| 30 | | | | |
| 31 | | | | |
| 32 | Linux kernel | | | |
| 33 | misc device <--- *QCEDEV Driver-------+ | | |
| 34 | interface (qcedev) (Reg interface) (DMA interface) |
| 35 | (for user space app) \ / |
| 36 | \ / |
| 37 | \ / |
| 38 | \ / |
| 39 | \ / |
| 40 | \ / |
| 41 | \ / |
| 42 | Qualcomm crypto CE3 HW |
| 43 | |
| 44 | |
| 45 | The entities marked with (*) in the Figure 1, are the software components of |
| 46 | the Linux Qualcomm crypto modules. |
| 47 | |
| 48 | =============== |
| 49 | IMPORTANT NOTE: |
| 50 | =============== |
| 51 | (1) The CE hardware can be accessed either from user space OR kernel space, |
| 52 | at one time. Both user space and kernel space clients cannot access the |
| 53 | qce driver (and the CE hardware) at the same time. |
| 54 | - If your device has user space apps that needs to access the crypto |
| 55 | hardware, make sure to have the qcrypto module disabled/unloaded. |
| 56 | This will result in the kernel space apps to use the registered |
| 57 | software implementation of the crypto algorithms. |
| 58 | - If your device has kernel space apps that needs to access the |
| 59 | crypto hardware, make sure to have qcedev module disabled/unloaded |
| 60 | and implement your user space application to use the software |
| 61 | implemenation (ex: openssl/crypto) of the crypto algorithms. |
| 62 | |
| 63 | (2) If your device has Playready(Windows Media DRM) application enabled and |
| 64 | uses the qcedev module to access the crypto hardware accelarator, |
| 65 | please be informed that for performance reasons, the CE hardware will need |
| 66 | to be dedicated to playready application. Any other user space application |
| 67 | should be implemented to use the software implemenation (ex: openssl/crypto) |
| 68 | of the crypto algorithms. |
| 69 | |
| 70 | |
| 71 | Hardware description: |
| 72 | ===================== |
| 73 | |
| 74 | Qualcomm Crypto HW device family provides a series of algorithms implemented |
| 75 | in the device hardware. |
| 76 | |
| 77 | Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES |
| 78 | algorithms, and concurrent operations of hashing, and ciphering. |
| 79 | |
| 80 | In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides |
| 81 | fast AES algorithms. |
| 82 | |
| 83 | In addition to those functions provided by Crypto 3 HW, Crypto 3E provides |
| 84 | HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as |
| 85 | defined by the 3GPP forum. |
| 86 | |
| 87 | |
| 88 | Software description |
| 89 | ==================== |
| 90 | |
| 91 | The crypto device is defined as a platform device. The driver is |
| 92 | independent of the platform. The driver supports multiple instances of |
| 93 | crypto HW. |
| 94 | All the platform specific parameters are defined in the board init |
| 95 | file, eg. arch/arm/mach-msm/board-msm7x30.c for MSM7x30. |
| 96 | |
| 97 | The qce driver provide the common services of HW crypto |
| 98 | access to the two drivers as listed above (qcedev, qcrypto. It sets up |
| 99 | the crypto HW device for the operation, then it requests ADM driver for |
| 100 | the DMA of the crypto operation. |
| 101 | |
| 102 | Two ADM channels and two command lists (one command list for each |
| 103 | channel) are involved in an operation. |
| 104 | |
| 105 | The setting up of the command lists and the procedure of the operation |
| 106 | of the crypto device are described in the following sections. |
| 107 | |
| 108 | The command list for the first DMA channel is set up as follows: |
| 109 | |
| 110 | 1st command of the list is for the DMA transfer from DDR memory to the |
| 111 | crypto device to input data to crypto device. The dst crci of the command |
| 112 | is set for crci-in for this crypto device. |
| 113 | |
| 114 | 2nd command is for the DMA tansfer is from crypto device to DDR memory for |
| 115 | the authentication result. The src crci is set as crci-hash-done of the |
| 116 | crypto device. If authentication is not required in the operation, |
| 117 | the 2nd command is not used. |
| 118 | |
| 119 | The command list for the second DMA channel is set up as follows: |
| 120 | |
| 121 | One command to DMA data from crypto device to DDR memory for encryption or |
| 122 | decryption output from crypto device. |
| 123 | |
| 124 | To accomplish ciphering and authentication concurrent operations, the driver |
| 125 | performs the following steps: |
| 126 | (a). set up HW crypto device |
| 127 | (b). hit the crypto go register. |
| 128 | (c). issue the DMA command of first channel to the ADM driver, |
| 129 | (d). issue the DMA command of 2nd channel to the ADM driver. |
| 130 | |
| 131 | SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish |
| 132 | hash operation (or any authentication only algorithm), 2nd DMA channel is |
| 133 | not required. Only steps (a) to (c) are performed. |
| 134 | |
| 135 | At the completion of the DMA operation (for (c) and (d)) ADM driver |
| 136 | invokes the callback registered to the DMA driver. This signifies the end of |
| 137 | the DMA operation(s). The driver reads the status and other information from |
| 138 | the CE hardware register and then invokes the callback to the qce driver client. |
| 139 | This signal the completion and the results of the DMA along with the status of |
| 140 | the CE hardware to the qce driver client. This completes a crypto operation. |
| 141 | |
| 142 | In the qce driver initialization, memory for the two command lists, descriptor |
| 143 | lists for each crypto device are allocated out of coherent memory, using Linux |
| 144 | DMA API. The driver pre-configures most of the two ADM command lists |
| 145 | in the initialization. During each crypto operation, minimal set up is required. |
| 146 | src_dscr or/and dst_dscr descriptor list of the ADM command are populated |
| 147 | from the information obtained from the corresponding data structure. eg: for |
| 148 | AEAD request, the following data structure provides the information: |
| 149 | |
| 150 | struct aead_request *req |
| 151 | ...... |
| 152 | req->assoc |
| 153 | req->src |
| 154 | req->dst |
| 155 | |
| 156 | The DMA address of a scatter list will be retrieved and set up in the |
| 157 | descriptor list of an ADM command. |
| 158 | |
| 159 | Power Management |
| 160 | ================ |
| 161 | none |
| 162 | |
| 163 | |
| 164 | Interface: |
| 165 | ========== |
| 166 | |
| 167 | The interface is defined in kernel/drivers/crypto/msm/inc/qce.h |
| 168 | |
| 169 | The clients qcrypto, qcedev drivers are the clients using |
| 170 | the interfaces. |
| 171 | |
| 172 | The following services are provided by the qce driver - |
| 173 | |
| 174 | qce_open(), qce_close(), qce_ablk_cipher_req(), |
| 175 | qce_hw_support(), qce_process_sha_req() |
| 176 | |
| 177 | qce_open() is the first request from the client, ex. Qualcomm crypto |
| 178 | driver (qcedev, qcrypto), to open a crypto engine. It is normally |
| 179 | called at the probe function of the client for a device. During the |
| 180 | probe, |
| 181 | - ADM command list structure will be set up |
| 182 | - Crypto device will be initialized. |
| 183 | - Resource associated with the crypto engine is retrieved by doing |
| 184 | platform_get_resource() or platform_get_resource_byname(). |
| 185 | |
| 186 | The resources for a device are |
| 187 | - crci-in, crci-out, crci-hash-done |
| 188 | - two DMA channel IDs, one for encryption and decryption input, one for |
| 189 | output. |
| 190 | - base address of the HW crypto device. |
| 191 | |
| 192 | qce_close() is the last request from the client. Normally, it is |
| 193 | called from the remove function of the client. |
| 194 | |
| 195 | qce_hw_support() allows the client to query what is supported |
| 196 | by the crypto engine hardware. |
| 197 | |
| 198 | qce_ablk_cipher_req() provides ciphering service to the client. |
| 199 | qce_process_sha_req() provide hashing service to the client. |
| 200 | qce_aead_req() provide aead service to the client. |
| 201 | |
| 202 | Module parameters: |
| 203 | ================== |
| 204 | |
| 205 | The following module parameters are defined in the board init file. |
| 206 | -CE hardware nase register address |
| 207 | -Data mover channel used for transfer to/from CE hardware |
| 208 | These parameters differ in each platform. |
| 209 | |
| 210 | |
| 211 | Dependencies: |
| 212 | ============= |
| 213 | |
| 214 | Existing DMA driver. |
| 215 | The transfers are DMA'ed between the crypto hardware and DDR memory via the |
| 216 | data mover, ADM. The data transfers are set up to use the existing dma driver. |
| 217 | |
| 218 | User space utilities: |
| 219 | ===================== |
| 220 | n/a |
| 221 | |
| 222 | Known issues: |
| 223 | ============= |
| 224 | n/a |
| 225 | |
| 226 | To do: |
| 227 | ====== |
| 228 | n/a |