From e898d9cdd3a9f105863d63dd3b46443742a4757c Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Thu, 20 Dec 2018 18:19:44 +0100 Subject: mailbox: Add device-managed registration functions Add device-managed equivalents of the mbox_controller_register() and mbox_controller_unregister() functions that can be used to have the devres infrastructure automatically unregister mailbox controllers on driver probe failure or driver removal. This can help remove a lot of boiler plate code from drivers. Reviewed-by: Bjorn Andersson Reviewed-by: Sudeep Holla Signed-off-by: Thierry Reding Signed-off-by: Jassi Brar --- include/linux/mailbox_controller.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'include') diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h index 74deadb42d76..9b0b21207345 100644 --- a/include/linux/mailbox_controller.h +++ b/include/linux/mailbox_controller.h @@ -131,4 +131,9 @@ void mbox_controller_unregister(struct mbox_controller *mbox); /* can sleep */ void mbox_chan_received_data(struct mbox_chan *chan, void *data); /* atomic */ void mbox_chan_txdone(struct mbox_chan *chan, int r); /* atomic */ +int devm_mbox_controller_register(struct device *dev, + struct mbox_controller *mbox); +void devm_mbox_controller_unregister(struct device *dev, + struct mbox_controller *mbox); + #endif /* __MAILBOX_CONTROLLER_H */ -- cgit v1.2.3 From a8803d7421cc2be2ac12a8155e5d824f04259eff Mon Sep 17 00:00:00 2001 From: Thierry Reding Date: Wed, 28 Nov 2018 10:54:10 +0100 Subject: mailbox: Support blocking transfers in atomic context The mailbox framework supports blocking transfers via completions for clients that can sleep. In order to support blocking transfers in cases where the transmission is not permitted to sleep, add a new ->flush() callback that controller drivers can implement to busy loop until the transmission has been completed. A new mbox_flush() function can be called by mailbox consumers in atomic context to make sure a transfer has completed. Signed-off-by: Thierry Reding Signed-off-by: Jassi Brar --- drivers/mailbox/mailbox.c | 28 ++++++++++++++++++++++++++++ include/linux/mailbox_client.h | 1 + include/linux/mailbox_controller.h | 4 ++++ 3 files changed, 33 insertions(+) (limited to 'include') diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index 08ce9a1ab53a..6abb35ff49fa 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -283,6 +283,34 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg) } EXPORT_SYMBOL_GPL(mbox_send_message); +/** + * mbox_flush - flush a mailbox channel + * @chan: mailbox channel to flush + * @timeout: time, in milliseconds, to allow the flush operation to succeed + * + * Mailbox controllers that need to work in atomic context can implement the + * ->flush() callback to busy loop until a transmission has been completed. + * The implementation must call mbox_chan_txdone() upon success. Clients can + * call the mbox_flush() function at any time after mbox_send_message() to + * flush the transmission. After the function returns success, the mailbox + * transmission is guaranteed to have completed. + * + * Returns: 0 on success or a negative error code on failure. + */ +int mbox_flush(struct mbox_chan *chan, unsigned long timeout) +{ + int ret; + + if (!chan->mbox->ops->flush) + return -ENOTSUPP; + + ret = chan->mbox->ops->flush(chan, timeout); + if (ret < 0) + tx_tick(chan, ret); + + return ret; +} + /** * mbox_request_channel - Request a mailbox channel. * @cl: Identity of the client requesting the channel. diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h index 44348710953f..faa7da3c9c8b 100644 --- a/include/linux/mailbox_client.h +++ b/include/linux/mailbox_client.h @@ -44,6 +44,7 @@ struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl, const char *name); struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index); int mbox_send_message(struct mbox_chan *chan, void *mssg); +int mbox_flush(struct mbox_chan *chan, unsigned long timeout); void mbox_client_txdone(struct mbox_chan *chan, int r); /* atomic */ bool mbox_client_peek_data(struct mbox_chan *chan); /* atomic */ void mbox_free_channel(struct mbox_chan *chan); /* may sleep */ diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h index 9b0b21207345..4994a438444c 100644 --- a/include/linux/mailbox_controller.h +++ b/include/linux/mailbox_controller.h @@ -24,6 +24,9 @@ struct mbox_chan; * transmission of data is reported by the controller via * mbox_chan_txdone (if it has some TX ACK irq). It must not * sleep. + * @flush: Called when a client requests transmissions to be blocking but + * the context doesn't allow sleeping. Typically the controller + * will implement a busy loop waiting for the data to flush out. * @startup: Called when a client requests the chan. The controller * could ask clients for additional parameters of communication * to be provided via client's chan_data. This call may @@ -46,6 +49,7 @@ struct mbox_chan; */ struct mbox_chan_ops { int (*send_data)(struct mbox_chan *chan, void *data); + int (*flush)(struct mbox_chan *chan, unsigned long timeout); int (*startup)(struct mbox_chan *chan); void (*shutdown)(struct mbox_chan *chan); bool (*last_tx_done)(struct mbox_chan *chan); -- cgit v1.2.3 From fed8b7e366e7c8f81e957ef91aa8f0a38e038c66 Mon Sep 17 00:00:00 2001 From: Mikko Perttunen Date: Wed, 28 Nov 2018 10:54:12 +0100 Subject: dt-bindings: tegra186-hsp: Add shared mailboxes Shared mailboxes are a mechanism to transport data from one processor in the system to another. They are bidirectional links with both a producer and a consumer. Interrupts are used to let the consumer know when data was written to the mailbox by the producer, and to let the producer know when the consumer has read the data from the mailbox. These interrupts are mapped to one or more "shared interrupts". Typically each processor in the system owns one of these shared interrupts. Add documentation to the device tree bindings about how clients can use mailbox specifiers to request a specific shared mailbox and select which direction they drive. Also document how to specify the shared interrupts in addition to the existing doorbell interrupt. Signed-off-by: Mikko Perttunen Acked-by: Jon Hunter Reviewed-by: Rob Herring Acked-by: Thierry Reding Signed-off-by: Thierry Reding Signed-off-by: Jassi Brar --- .../bindings/mailbox/nvidia,tegra186-hsp.txt | 30 ++++++++++++++++++---- include/dt-bindings/mailbox/tegra186-hsp.h | 11 ++++++++ 2 files changed, 36 insertions(+), 5 deletions(-) (limited to 'include') diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt index b99d25fc2f26..ff3eafc5a882 100644 --- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt @@ -15,12 +15,15 @@ Required properties: Array of strings. one of: - "nvidia,tegra186-hsp" + - "nvidia,tegra194-hsp", "nvidia,tegra186-hsp" - reg : Offset and length of the register set for the device. - interrupt-names Array of strings. Contains a list of names for the interrupts described by the interrupt property. May contain the following entries, in any order: - "doorbell" + - "sharedN", where 'N' is a number from zero up to the number of + external interrupts supported by the HSP instance minus one. Users of this binding MUST look up entries in the interrupt property by name, using this interrupt-names property to do so. - interrupts @@ -29,12 +32,29 @@ Required properties: in a matching order. - #mbox-cells : Should be 2. -The mbox specifier of the "mboxes" property in the client node should -contain two data. The first one should be the HSP type and the second -one should be the ID that the client is going to use. Those information -can be found in the following file. +The mbox specifier of the "mboxes" property in the client node should contain +two cells. The first cell determines the HSP type and the second cell is used +to identify the mailbox that the client is going to use. -- . +For doorbells, the second cell specifies the index of the doorbell to use. + +For shared mailboxes, the second cell is composed of two fields: +- bits 31..24: + A bit mask of flags that further specify how the shared mailbox will be + used. Valid flags are: + - bit 31: + Defines the direction of the mailbox. If set, the mailbox will be used + as a producer (i.e. used to send data). If cleared, the mailbox is the + consumer of data sent by a producer. + +- bits 23.. 0: + The index of the shared mailbox to use. The number of available mailboxes + may vary by instance of the HSP block and SoC generation. + +The following file contains definitions that can be used to construct mailbox +specifiers: + + Example: diff --git a/include/dt-bindings/mailbox/tegra186-hsp.h b/include/dt-bindings/mailbox/tegra186-hsp.h index bcab5b7ca785..3bdec7a84d35 100644 --- a/include/dt-bindings/mailbox/tegra186-hsp.h +++ b/include/dt-bindings/mailbox/tegra186-hsp.h @@ -22,4 +22,15 @@ #define TEGRA_HSP_DB_MASTER_CCPLEX 17 #define TEGRA_HSP_DB_MASTER_BPMP 19 +/* + * Shared mailboxes are unidirectional, so the direction needs to be specified + * in the device tree. + */ +#define TEGRA_HSP_SM_MASK 0x00ffffff +#define TEGRA_HSP_SM_FLAG_RX (0 << 31) +#define TEGRA_HSP_SM_FLAG_TX (1 << 31) + +#define TEGRA_HSP_SM_RX(x) (TEGRA_HSP_SM_FLAG_RX | ((x) & TEGRA_HSP_SM_MASK)) +#define TEGRA_HSP_SM_TX(x) (TEGRA_HSP_SM_FLAG_TX | ((x) & TEGRA_HSP_SM_MASK)) + #endif -- cgit v1.2.3