litmus-rt.git - The LITMUS^RT kernel.

diff options

author	Martin Schwidefsky <schwidefsky@de.ibm.com>	2009-06-22 06:08:22 -0400
committer	Martin Schwidefsky <schwidefsky@de.ibm.com>	2009-06-22 06:08:24 -0400
commit	12310e9c1b9a53896e4df0459039dd125f62aa9b (patch)
tree	99a629bc1711c72e67ab0e9e86730ef69a563bad /net/lapb/lapb_subr.c
parent	181d95229b0931ee2ce6aad7348079cbc10e8d05 (diff)

[S390] Enable tick based perf_counter on s390.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

Diffstat (limited to 'net/lapb/lapb_subr.c')

0 files changed, 0 insertions, 0 deletions

/* * Shared Transport Header file * To be included by the protocol stack drivers for * Texas Instruments BT,FM and GPS combo chip drivers * and also serves the sub-modules of the shared transport driver. * * Copyright (C) 2009-2010 Texas Instruments * Author: Pavan Savoy <pavan_savoy@ti.com> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * */ #ifndef TI_WILINK_ST_H #define TI_WILINK_ST_H #include <linux/skbuff.h> /** * enum proto-type - The protocol on WiLink chips which share a * common physical interface like UART. */ enum proto_type { ST_BT, ST_FM, ST_GPS, ST_MAX_CHANNELS = 16, }; /** * struct st_proto_s - Per Protocol structure from BT/FM/GPS to ST * @type: type of the protocol being registered among the * available proto_type(BT, FM, GPS the protocol which share TTY). * @recv: the receiver callback pointing to a function in the * protocol drivers called by the ST driver upon receiving * relevant data. * @match_packet: reserved for future use, to make ST more generic * @reg_complete_cb: callback handler pointing to a function in protocol * handler called by ST when the pending registrations are complete. * The registrations are marked pending, in situations when fw * download is in progress. * @write: pointer to function in ST provided to protocol drivers from ST, * to be made use when protocol drivers have data to send to TTY. * @priv_data: privdate data holder for the protocol drivers, sent * from the protocol drivers during registration, and sent back on * reg_complete_cb and recv. * @chnl_id: channel id the protocol driver is interested in, the channel * id is nothing but the 1st byte of the packet in UART frame. * @max_frame_size: size of the largest frame the protocol can receive. * @hdr_len: length of the header structure of the protocol. * @offset_len_in_hdr: this provides the offset of the length field in the * header structure of the protocol header, to assist ST to know * how much to receive, if the data is split across UART frames. * @len_size: whether the length field inside the header is 2 bytes * or 1 byte. * @reserve: the number of bytes ST needs to reserve in the skb being * prepared for the protocol driver. */ struct st_proto_s { enum proto_type type; long (*recv) (void *, struct sk_buff *); unsigned char (*match_packet) (const unsigned char *data); void (*reg_complete_cb) (void *, char data); long (*write) (struct sk_buff *skb); void *priv_data; unsigned char chnl_id; unsigned short max_frame_size; unsigned char hdr_len; unsigned char offset_len_in_hdr; unsigned char len_size; unsigned char reserve; }; extern long st_register(struct st_proto_s *); extern long st_unregister(struct st_proto_s *); /* * header information used by st_core.c */ /* states of protocol list */ #define ST_NOTEMPTY 1 #define ST_EMPTY 0 /* * possible st_states */ #define ST_INITIALIZING 1 #define ST_REG_IN_PROGRESS 2 #define ST_REG_PENDING 3 #define ST_WAITING_FOR_RESP 4 /** * struct st_data_s - ST core internal structure * @st_state: different states of ST like initializing, registration * in progress, this is mainly used to return relevant err codes * when protocol drivers are registering. It is also used to track * the recv function, as in during fw download only HCI events * can occur , where as during other times other events CH8, CH9 * can occur. * @tty: tty provided by the TTY core for line disciplines. * @tx_skb: If for some reason the tty's write returns lesser bytes written * then to maintain the rest of data to be written on next instance. * This needs to be protected, hence the lock inside wakeup func. * @tx_state: if the data is being written onto the TTY and protocol driver * wants to send more, queue up data and mark that there is * more data to send. * @list: the list of protocols registered, only MAX can exist, one protocol * can register only once. * @rx_state: states to be maintained inside st's tty receive * @rx_count: count to be maintained inside st's tty receieve * @rx_skb: the skb where all data for a protocol gets accumulated, * since tty might not call receive when a complete event packet * is received, the states, count and the skb needs to be maintained. * @rx_chnl: the channel ID for which the data is getting accumalated for. * @txq: the list of skbs which needs to be sent onto the TTY. * @tx_waitq: if the chip is not in AWAKE state, the skbs needs to be queued * up in here, PM(WAKEUP_IND) data needs to be sent and then the skbs * from waitq can be moved onto the txq. * Needs locking too.


context:
space:
mode: