1/* 2 * Shared Transport Line discipline driver Core 3 * Init Manager Module header file 4 * Copyright (C) 2009 Texas Instruments 5 * 6 * This program is free software; you can redistribute it and/or modify 7 * it under the terms of the GNU General Public License version 2 as 8 * published by the Free Software Foundation. 9 * 10 * This program is distributed in the hope that it will be useful, 11 * but WITHOUT ANY WARRANTY; without even the implied warranty of 12 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 13 * GNU General Public License for more details. 14 * 15 * You should have received a copy of the GNU General Public License 16 * along with this program; if not, write to the Free Software 17 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 18 * 19 */ 20 21#ifndef ST_KIM_H 22#define ST_KIM_H 23 24#include <linux/types.h> 25#include "st.h" 26#include "st_core.h" 27#include "st_ll.h" 28#include <linux/rfkill.h> 29 30/* time in msec to wait for 31 * line discipline to be installed 32 */ 33#define LDISC_TIME 500 34#define CMD_RESP_TIME 500 35#define MAKEWORD(a, b) ((unsigned short)(((unsigned char)(a)) \ 36 | ((unsigned short)((unsigned char)(b))) << 8)) 37 38#define GPIO_HIGH 1 39#define GPIO_LOW 0 40 41/* the Power-On-Reset logic, requires to attempt 42 * to download firmware onto chip more than once 43 * since the self-test for chip takes a while 44 */ 45#define POR_RETRY_COUNT 5 46 47/** 48 * struct chip_version - save the chip version 49 */ 50struct chip_version { 51 unsigned short full; 52 unsigned short chip; 53 unsigned short min_ver; 54 unsigned short maj_ver; 55}; 56 57/** 58 * struct kim_data_s - the KIM internal data, embedded as the 59 * platform's drv data. One for each ST device in the system. 60 * @uim_pid: KIM needs to communicate with UIM to request to install 61 * the ldisc by opening UART when protocol drivers register. 62 * @kim_pdev: the platform device added in one of the board-XX.c file 63 * in arch/XX/ directory, 1 for each ST device. 64 * @kim_rcvd: completion handler to notify when data was received, 65 * mainly used during fw download, which involves multiple send/wait 66 * for each of the HCI-VS commands. 67 * @ldisc_installed: completion handler to notify that the UIM accepted 68 * the request to install ldisc, notify from tty_open which suggests 69 * the ldisc was properly installed. 70 * @resp_buffer: data buffer for the .bts fw file name. 71 * @fw_entry: firmware class struct to request/release the fw. 72 * @gpios: the list of core/chip enable gpios for BT, FM and GPS cores. 73 * @rx_state: the rx state for kim's receive func during fw download. 74 * @rx_count: the rx count for the kim's receive func during fw download. 75 * @rx_skb: all of fw data might not come at once, and hence data storage for 76 * whole of the fw response, only HCI_EVENTs and hence diff from ST's 77 * response. 78 * @rfkill: rfkill data for each of the cores to be registered with rfkill. 79 * @rf_protos: proto types of the data registered with rfkill sub-system. 80 * @core_data: ST core's data, which mainly is the tty's disc_data 81 * @version: chip version available via a sysfs entry. 82 * 83 */ 84struct kim_data_s { 85 long uim_pid; 86 struct platform_device *kim_pdev; 87 struct completion kim_rcvd, ldisc_installed; 88 char resp_buffer[30]; 89 const struct firmware *fw_entry; 90 long gpios[ST_MAX]; 91 unsigned long rx_state; 92 unsigned long rx_count; 93 struct sk_buff *rx_skb; 94 struct rfkill *rfkill[ST_MAX]; 95 enum proto_type rf_protos[ST_MAX]; 96 struct st_data_s *core_data; 97 struct chip_version version; 98}; 99 100/** 101 * functions called when 1 of the protocol drivers gets 102 * registered, these need to communicate with UIM to request 103 * ldisc installed, read chip_version, download relevant fw 104 */ 105long st_kim_start(void *); 106long st_kim_stop(void *); 107 108void st_kim_recv(void *, const unsigned char *, long count); 109void st_kim_chip_toggle(enum proto_type, enum kim_gpio_state); 110void st_kim_complete(void *); 111void kim_st_list_protocols(struct st_data_s *, void *); 112 113/* 114 * BTS headers 115 */ 116#define ACTION_SEND_COMMAND 1 117#define ACTION_WAIT_EVENT 2 118#define ACTION_SERIAL 3 119#define ACTION_DELAY 4 120#define ACTION_RUN_SCRIPT 5 121#define ACTION_REMARKS 6 122 123/** 124 * struct bts_header - the fw file is NOT binary which can 125 * be sent onto TTY as is. The .bts is more a script 126 * file which has different types of actions. 127 * Each such action needs to be parsed by the KIM and 128 * relevant procedure to be called. 129 */ 130struct bts_header { 131 uint32_t magic; 132 uint32_t version; 133 uint8_t future[24]; 134 uint8_t actions[0]; 135} __attribute__ ((packed)); 136 137/** 138 * struct bts_action - Each .bts action has its own type of 139 * data. 140 */ 141struct bts_action { 142 uint16_t type; 143 uint16_t size; 144 uint8_t data[0]; 145} __attribute__ ((packed)); 146 147struct bts_action_send { 148 uint8_t data[0]; 149} __attribute__ ((packed)); 150 151struct bts_action_wait { 152 uint32_t msec; 153 uint32_t size; 154 uint8_t data[0]; 155} __attribute__ ((packed)); 156 157struct bts_action_delay { 158 uint32_t msec; 159} __attribute__ ((packed)); 160 161struct bts_action_serial { 162 uint32_t baud; 163 uint32_t flow_control; 164} __attribute__ ((packed)); 165 166/** 167 * struct hci_command - the HCI-VS for intrepreting 168 * the change baud rate of host-side UART, which 169 * needs to be ignored, since UIM would do that 170 * when it receives request from KIM for ldisc installation. 171 */ 172struct hci_command { 173 uint8_t prefix; 174 uint16_t opcode; 175 uint8_t plen; 176 uint32_t speed; 177} __attribute__ ((packed)); 178 179 180#endif /* ST_KIM_H */ 181