Loading...
1/* SPDX-License-Identifier: GPL-2.0-only */
2
3#ifndef __MAILBOX_CONTROLLER_H
4#define __MAILBOX_CONTROLLER_H
5
6#include <linux/of.h>
7#include <linux/types.h>
8#include <linux/hrtimer.h>
9#include <linux/device.h>
10#include <linux/completion.h>
11
12struct mbox_chan;
13
14/**
15 * struct mbox_chan_ops - methods to control mailbox channels
16 * @send_data: The API asks the MBOX controller driver, in atomic
17 * context try to transmit a message on the bus. Returns 0 if
18 * data is accepted for transmission, -EBUSY while rejecting
19 * if the remote hasn't yet read the last data sent. Actual
20 * transmission of data is reported by the controller via
21 * mbox_chan_txdone (if it has some TX ACK irq). It must not
22 * sleep.
23 * @flush: Called when a client requests transmissions to be blocking but
24 * the context doesn't allow sleeping. Typically the controller
25 * will implement a busy loop waiting for the data to flush out.
26 * @startup: Called when a client requests the chan. The controller
27 * could ask clients for additional parameters of communication
28 * to be provided via client's chan_data. This call may
29 * block. After this call the Controller must forward any
30 * data received on the chan by calling mbox_chan_received_data.
31 * The controller may do stuff that need to sleep.
32 * @shutdown: Called when a client relinquishes control of a chan.
33 * This call may block too. The controller must not forward
34 * any received data anymore.
35 * The controller may do stuff that need to sleep.
36 * @last_tx_done: If the controller sets 'txdone_poll', the API calls
37 * this to poll status of last TX. The controller must
38 * give priority to IRQ method over polling and never
39 * set both txdone_poll and txdone_irq. Only in polling
40 * mode 'send_data' is expected to return -EBUSY.
41 * The controller may do stuff that need to sleep/block.
42 * Used only if txdone_poll:=true && txdone_irq:=false
43 * @peek_data: Atomic check for any received data. Return true if controller
44 * has some data to push to the client. False otherwise.
45 */
46struct mbox_chan_ops {
47 int (*send_data)(struct mbox_chan *chan, void *data);
48 int (*flush)(struct mbox_chan *chan, unsigned long timeout);
49 int (*startup)(struct mbox_chan *chan);
50 void (*shutdown)(struct mbox_chan *chan);
51 bool (*last_tx_done)(struct mbox_chan *chan);
52 bool (*peek_data)(struct mbox_chan *chan);
53};
54
55/**
56 * struct mbox_controller - Controller of a class of communication channels
57 * @dev: Device backing this controller
58 * @ops: Operators that work on each communication chan
59 * @chans: Array of channels
60 * @num_chans: Number of channels in the 'chans' array.
61 * @txdone_irq: Indicates if the controller can report to API when
62 * the last transmitted data was read by the remote.
63 * Eg, if it has some TX ACK irq.
64 * @txdone_poll: If the controller can read but not report the TX
65 * done. Ex, some register shows the TX status but
66 * no interrupt rises. Ignored if 'txdone_irq' is set.
67 * @txpoll_period: If 'txdone_poll' is in effect, the API polls for
68 * last TX's status after these many millisecs
69 * @of_xlate: Controller driver specific mapping of channel via DT
70 * @poll_hrt: API private. hrtimer used to poll for TXDONE on all
71 * channels.
72 * @node: API private. To hook into list of controllers.
73 */
74struct mbox_controller {
75 struct device *dev;
76 const struct mbox_chan_ops *ops;
77 struct mbox_chan *chans;
78 int num_chans;
79 bool txdone_irq;
80 bool txdone_poll;
81 unsigned txpoll_period;
82 struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
83 const struct of_phandle_args *sp);
84 /* Internal to API */
85 struct hrtimer poll_hrt;
86 struct list_head node;
87};
88
89/*
90 * The length of circular buffer for queuing messages from a client.
91 * 'msg_count' tracks the number of buffered messages while 'msg_free'
92 * is the index where the next message would be buffered.
93 * We shouldn't need it too big because every transfer is interrupt
94 * triggered and if we have lots of data to transfer, the interrupt
95 * latencies are going to be the bottleneck, not the buffer length.
96 * Besides, mbox_send_message could be called from atomic context and
97 * the client could also queue another message from the notifier 'tx_done'
98 * of the last transfer done.
99 * REVISIT: If too many platforms see the "Try increasing MBOX_TX_QUEUE_LEN"
100 * print, it needs to be taken from config option or somesuch.
101 */
102#define MBOX_TX_QUEUE_LEN 20
103
104/**
105 * struct mbox_chan - s/w representation of a communication chan
106 * @mbox: Pointer to the parent/provider of this channel
107 * @txdone_method: Way to detect TXDone chosen by the API
108 * @cl: Pointer to the current owner of this channel
109 * @tx_complete: Transmission completion
110 * @active_req: Currently active request hook
111 * @msg_count: No. of mssg currently queued
112 * @msg_free: Index of next available mssg slot
113 * @msg_data: Hook for data packet
114 * @lock: Serialise access to the channel
115 * @con_priv: Hook for controller driver to attach private data
116 */
117struct mbox_chan {
118 struct mbox_controller *mbox;
119 unsigned txdone_method;
120 struct mbox_client *cl;
121 struct completion tx_complete;
122 void *active_req;
123 unsigned msg_count, msg_free;
124 void *msg_data[MBOX_TX_QUEUE_LEN];
125 spinlock_t lock; /* Serialise access to the channel */
126 void *con_priv;
127};
128
129int mbox_controller_register(struct mbox_controller *mbox); /* can sleep */
130void mbox_controller_unregister(struct mbox_controller *mbox); /* can sleep */
131void mbox_chan_received_data(struct mbox_chan *chan, void *data); /* atomic */
132void mbox_chan_txdone(struct mbox_chan *chan, int r); /* atomic */
133
134int devm_mbox_controller_register(struct device *dev,
135 struct mbox_controller *mbox);
136void devm_mbox_controller_unregister(struct device *dev,
137 struct mbox_controller *mbox);
138
139#endif /* __MAILBOX_CONTROLLER_H */
1/* SPDX-License-Identifier: GPL-2.0-only */
2
3#ifndef __MAILBOX_CONTROLLER_H
4#define __MAILBOX_CONTROLLER_H
5
6#include <linux/of.h>
7#include <linux/types.h>
8#include <linux/hrtimer.h>
9#include <linux/device.h>
10#include <linux/completion.h>
11
12struct mbox_chan;
13
14/**
15 * struct mbox_chan_ops - methods to control mailbox channels
16 * @send_data: The API asks the MBOX controller driver, in atomic
17 * context try to transmit a message on the bus. Returns 0 if
18 * data is accepted for transmission, -EBUSY while rejecting
19 * if the remote hasn't yet read the last data sent. Actual
20 * transmission of data is reported by the controller via
21 * mbox_chan_txdone (if it has some TX ACK irq). It must not
22 * sleep.
23 * @flush: Called when a client requests transmissions to be blocking but
24 * the context doesn't allow sleeping. Typically the controller
25 * will implement a busy loop waiting for the data to flush out.
26 * @startup: Called when a client requests the chan. The controller
27 * could ask clients for additional parameters of communication
28 * to be provided via client's chan_data. This call may
29 * block. After this call the Controller must forward any
30 * data received on the chan by calling mbox_chan_received_data.
31 * The controller may do stuff that need to sleep.
32 * @shutdown: Called when a client relinquishes control of a chan.
33 * This call may block too. The controller must not forward
34 * any received data anymore.
35 * The controller may do stuff that need to sleep.
36 * @last_tx_done: If the controller sets 'txdone_poll', the API calls
37 * this to poll status of last TX. The controller must
38 * give priority to IRQ method over polling and never
39 * set both txdone_poll and txdone_irq. Only in polling
40 * mode 'send_data' is expected to return -EBUSY.
41 * The controller may do stuff that need to sleep/block.
42 * Used only if txdone_poll:=true && txdone_irq:=false
43 * @peek_data: Atomic check for any received data. Return true if controller
44 * has some data to push to the client. False otherwise.
45 */
46struct mbox_chan_ops {
47 int (*send_data)(struct mbox_chan *chan, void *data);
48 int (*flush)(struct mbox_chan *chan, unsigned long timeout);
49 int (*startup)(struct mbox_chan *chan);
50 void (*shutdown)(struct mbox_chan *chan);
51 bool (*last_tx_done)(struct mbox_chan *chan);
52 bool (*peek_data)(struct mbox_chan *chan);
53};
54
55/**
56 * struct mbox_controller - Controller of a class of communication channels
57 * @dev: Device backing this controller
58 * @ops: Operators that work on each communication chan
59 * @chans: Array of channels
60 * @num_chans: Number of channels in the 'chans' array.
61 * @txdone_irq: Indicates if the controller can report to API when
62 * the last transmitted data was read by the remote.
63 * Eg, if it has some TX ACK irq.
64 * @txdone_poll: If the controller can read but not report the TX
65 * done. Ex, some register shows the TX status but
66 * no interrupt rises. Ignored if 'txdone_irq' is set.
67 * @txpoll_period: If 'txdone_poll' is in effect, the API polls for
68 * last TX's status after these many millisecs
69 * @of_xlate: Controller driver specific mapping of channel via DT
70 * @poll_hrt: API private. hrtimer used to poll for TXDONE on all
71 * channels.
72 * @node: API private. To hook into list of controllers.
73 */
74struct mbox_controller {
75 struct device *dev;
76 const struct mbox_chan_ops *ops;
77 struct mbox_chan *chans;
78 int num_chans;
79 bool txdone_irq;
80 bool txdone_poll;
81 unsigned txpoll_period;
82 struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
83 const struct of_phandle_args *sp);
84 /* Internal to API */
85 struct hrtimer poll_hrt;
86 spinlock_t poll_hrt_lock;
87 struct list_head node;
88};
89
90/*
91 * The length of circular buffer for queuing messages from a client.
92 * 'msg_count' tracks the number of buffered messages while 'msg_free'
93 * is the index where the next message would be buffered.
94 * We shouldn't need it too big because every transfer is interrupt
95 * triggered and if we have lots of data to transfer, the interrupt
96 * latencies are going to be the bottleneck, not the buffer length.
97 * Besides, mbox_send_message could be called from atomic context and
98 * the client could also queue another message from the notifier 'tx_done'
99 * of the last transfer done.
100 * REVISIT: If too many platforms see the "Try increasing MBOX_TX_QUEUE_LEN"
101 * print, it needs to be taken from config option or somesuch.
102 */
103#define MBOX_TX_QUEUE_LEN 20
104
105/**
106 * struct mbox_chan - s/w representation of a communication chan
107 * @mbox: Pointer to the parent/provider of this channel
108 * @txdone_method: Way to detect TXDone chosen by the API
109 * @cl: Pointer to the current owner of this channel
110 * @tx_complete: Transmission completion
111 * @active_req: Currently active request hook
112 * @msg_count: No. of mssg currently queued
113 * @msg_free: Index of next available mssg slot
114 * @msg_data: Hook for data packet
115 * @lock: Serialise access to the channel
116 * @con_priv: Hook for controller driver to attach private data
117 */
118struct mbox_chan {
119 struct mbox_controller *mbox;
120 unsigned txdone_method;
121 struct mbox_client *cl;
122 struct completion tx_complete;
123 void *active_req;
124 unsigned msg_count, msg_free;
125 void *msg_data[MBOX_TX_QUEUE_LEN];
126 spinlock_t lock; /* Serialise access to the channel */
127 void *con_priv;
128};
129
130int mbox_controller_register(struct mbox_controller *mbox); /* can sleep */
131void mbox_controller_unregister(struct mbox_controller *mbox); /* can sleep */
132void mbox_chan_received_data(struct mbox_chan *chan, void *data); /* atomic */
133void mbox_chan_txdone(struct mbox_chan *chan, int r); /* atomic */
134
135int devm_mbox_controller_register(struct device *dev,
136 struct mbox_controller *mbox);
137void devm_mbox_controller_unregister(struct device *dev,
138 struct mbox_controller *mbox);
139
140#endif /* __MAILBOX_CONTROLLER_H */