Once upon a time, Apple machines had some mailbox hardware, and we had
to write a driver for it. And since it was a mailbox, it felt natural to
use the Linux mailbox subsystem.
More than a year later, it has become evident that was not the right
decision.
Linux driver class subsystems generally exist for a few purposes:
1. To allow mixing and matching generic producers and consumers.
2. To implement common code that is likely to be shared across drivers,
and do so correctly so correct code only has to be written once.
3. To force drivers into a "correct" design, such that driver authors
avoid common pitfalls.
The mailbox subsystem does not do any of the above for us:
1. Mailbox hardware is not generic; "mailbox" is a vague idea, not a
standard for communication. Almost all mailbox consumers are tied to
one or a few producers. There is practically no mixing and matching
possible. We have one (1) consumer subsystem (RTKit) talking to one
(1) mailbox driver (apple-mailbox). We might have a second consumer
in the future (SEP), but there will still be no useful
combinatronics with other drivers.
2. The mailbox subsystem implements a bunch of common code for queuing,
but we don't need that because our hardware has hardware queues. It
also implements a bunch of common code for supporting multiple
channels, but we don't need that because our hardware only has one
channel (it has "endpoints" but those are just tags that are part of
the message). On top of this, the mailbox subsystem makes design
decisions unsuitable for our use case. Its queuing implementation
has a fixed queue size and fails sends when full instead of pushing
back by blocking, which is completely unsuitable for high-traffic
mailboxes with hard reliability requirements, such as ours. We've
also run into multiple issues around using mailbox in an atomic
context (required for SMC reboot/shutdown requests).
3. Mailbox doesn't really do much for us as far as driver design.
If anything, it has been forcing us to add extra workarounds for the
impedance mismatches between the subsystem core and the hardware.
Other drivers already are inconsistent in how they use the mailbox
core, because the documentation is unclear on various details.
The interface for mailboxes is very simple - basically just a send() and
a receive callback. This series quite literally just rips out the
middleman, and connects both sides together directly. There just isn't
anything useful the mailbox common code is doing for us - it's just a
pile of complexity in the middle that adds bugs, impedance mismatches,
overhead, and offers no extra features we can use.
This series offers:
- A modest reduction in overall code size (-27 net lines excluding #1).
- Fixes a pile of bugs related to using the mailbox subsystem and its
quirks and limitations (race conditions when messages are already in
the queue on startup, atomic issues, the list goes on).
- Adds runtime-PM support.
- Adds support for the FIFOs in the mailbox hardware, improving
performance.
- Simplifies code by removing extraneous memory allocations (the
mailbox subsystem requires consumers to pass pointers to messages,
instead of inlining them, even though messages are usually only one or
two registers in size) and the requisite cleanup/freeing in the
completion path.
In addition, it paves the way for future Apple-specific mailbox
optimizations, such as adding the ability to de-duplicate message sends
if the same message is already known to be in the FIFO (which can be
done by keeping a rolling history of recently sent messages). This is
useful for doorbell-style messages, which are redundant to send more
than once if not yet processed.
Apple Silicon platforms use these mailboxes pervasively, including as
part of the GPU submission hot path. On top of that, bad interactions
with firmware coprocessors can cause immediate lockups or crashes with
no recovery possible but a reboot. Our requirements for reliability and
performance are probably much higher than the average mailbox user, and
we'd much rather not have a bunch of common code getting in the way of
performance profiling and future optimization. It doesn't make much
sense for the mailbox subsystem either, since solving these issues would
require major refactoring that is unlikely to provide significant
benefit to most other users.
So let's just call usage of the mailbox subsystem a failed experiment,
and move the driver into soc/apple, where we can control the API and can
add whatever peculiarities we need for our mailboxes. Farewell, mailbox.
There are no changes to the DT bindings. This driver has been shipping
in Asahi stable kernel packages for a week, with no regressions
reported by any users.
As an additional non-kernel-related benefit, this introduces a direct
module dependency between consumers and the mailbox producer. This, in
turn, is in the critical path for the NVMe driver on these platforms.
Prior to this series, we had to have custom initramfs hooks to add
apple-mailbox to distro initramfses, and accidentally removing these
hooks would result in a completely unbootable system (there is no way
for standard initramfs machinery to detect soft consumer/producer
relationships like this, they usually just go looking for block device
modules and their direct dependencies). We still need the initramfs
hooks for other things, but with this change, completely removing all
Apple-related initramfs hooks will at least result in a *bootable*
system so you can fix the problem. This has already bit several users,
and it also means many more distros have a chance of working out of the
box (enough to let you install extra stuff) on these platforms, instead
of having a hard requirement that *every single distro* fix up their
initramfs generation in order to even boot/install on these platforms at
all.
Jassi: Ideally I'd like to get an ack on this and merge it all through
asahi-soc, so we don't have to play things patch-by-patch across
multiple merge cycles to avoid potentially broken intermediate states.
Signed-off-by: Hector Martin <[email protected]>
---
Hector Martin (5):
soc: apple: rtkit: Get rid of apple_rtkit_send_message_wait
soc: apple: mailbox: Add ASC/M3 mailbox driver
soc: apple: rtkit: Port to the internal mailbox driver
mailbox: apple: Delete driver
soc: apple: mailbox: Rename config symbol to APPLE_MAILBOX
MAINTAINERS | 2 -
drivers/mailbox/Kconfig | 12 -
drivers/mailbox/Makefile | 2 -
drivers/mailbox/apple-mailbox.c | 441 -------------------------------------
drivers/soc/apple/Kconfig | 15 +-
drivers/soc/apple/Makefile | 3 +
drivers/soc/apple/mailbox.c | 434 ++++++++++++++++++++++++++++++++++++
drivers/soc/apple/mailbox.h | 48 ++++
drivers/soc/apple/rtkit-internal.h | 8 +-
drivers/soc/apple/rtkit.c | 133 +++--------
include/linux/apple-mailbox.h | 19 --
include/linux/soc/apple/rtkit.h | 18 --
12 files changed, 529 insertions(+), 606 deletions(-)
---
base-commit: bdfe6de2695c5bccc663a5a7d530f81925d8bc10
change-id: 20230328-soc-mailbox-3cb6bb2b0b2d
Best regards,
--
Hector Martin <[email protected]>
It is fundamentally broken and has no users. Just remove it.
Signed-off-by: Hector Martin <[email protected]>
---
drivers/soc/apple/rtkit.c | 32 --------------------------------
include/linux/soc/apple/rtkit.h | 18 ------------------
2 files changed, 50 deletions(-)
diff --git a/drivers/soc/apple/rtkit.c b/drivers/soc/apple/rtkit.c
index d9f19dc99da5..7c9b9f25bbc1 100644
--- a/drivers/soc/apple/rtkit.c
+++ b/drivers/soc/apple/rtkit.c
@@ -641,38 +641,6 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
}
EXPORT_SYMBOL_GPL(apple_rtkit_send_message);
-int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message,
- unsigned long timeout, bool atomic)
-{
- DECLARE_COMPLETION_ONSTACK(completion);
- int ret;
- long t;
-
- ret = apple_rtkit_send_message(rtk, ep, message, &completion, atomic);
- if (ret < 0)
- return ret;
-
- if (atomic) {
- ret = mbox_flush(rtk->mbox_chan, timeout);
- if (ret < 0)
- return ret;
-
- if (try_wait_for_completion(&completion))
- return 0;
-
- return -ETIME;
- } else {
- t = wait_for_completion_interruptible_timeout(
- &completion, msecs_to_jiffies(timeout));
- if (t < 0)
- return t;
- else if (t == 0)
- return -ETIME;
- return 0;
- }
-}
-EXPORT_SYMBOL_GPL(apple_rtkit_send_message_wait);
-
int apple_rtkit_poll(struct apple_rtkit *rtk)
{
return mbox_client_peek_data(rtk->mbox_chan);
diff --git a/include/linux/soc/apple/rtkit.h b/include/linux/soc/apple/rtkit.h
index fc456f75c131..8c9ca857ccf6 100644
--- a/include/linux/soc/apple/rtkit.h
+++ b/include/linux/soc/apple/rtkit.h
@@ -160,24 +160,6 @@ int apple_rtkit_start_ep(struct apple_rtkit *rtk, u8 endpoint);
int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
struct completion *completion, bool atomic);
-/*
- * Send a message to the given endpoint and wait until it has been submitted
- * to the hardware FIFO.
- * Will return zero on success and a negative error code on failure
- * (e.g. -ETIME when the message couldn't be written within the given
- * timeout)
- *
- * @rtk: RTKit reference
- * @ep: target endpoint
- * @message: message to be sent
- * @timeout: timeout in milliseconds to allow the message transmission
- * to be completed
- * @atomic: if set to true this function can be called from atomic
- * context.
- */
-int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message,
- unsigned long timeout, bool atomic);
-
/*
* Process incoming messages in atomic context.
* This only guarantees that messages arrive as far as the recv_message_early
--
2.40.0
Now that we have a mailbox driver in drivers/soc/apple, port the RTKit
code to it. This mostly just entails replacing calls through the mailbox
subsystem with direct calls into the driver.
Signed-off-by: Hector Martin <[email protected]>
---
drivers/soc/apple/Kconfig | 2 +-
drivers/soc/apple/rtkit-internal.h | 8 +--
drivers/soc/apple/rtkit.c | 101 ++++++++++---------------------------
3 files changed, 31 insertions(+), 80 deletions(-)
diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
index caa2cf09ff7a..d0e29bbd8c6f 100644
--- a/drivers/soc/apple/Kconfig
+++ b/drivers/soc/apple/Kconfig
@@ -33,7 +33,7 @@ config APPLE_MBOX
config APPLE_RTKIT
tristate "Apple RTKit co-processor IPC protocol"
- depends on MAILBOX
+ depends on APPLE_MBOX
depends on ARCH_APPLE || COMPILE_TEST
default ARCH_APPLE
help
diff --git a/drivers/soc/apple/rtkit-internal.h b/drivers/soc/apple/rtkit-internal.h
index 24bd619ec5e4..27c9fa745fd5 100644
--- a/drivers/soc/apple/rtkit-internal.h
+++ b/drivers/soc/apple/rtkit-internal.h
@@ -7,18 +7,17 @@
#ifndef _APPLE_RTKIT_INTERAL_H
#define _APPLE_RTKIT_INTERAL_H
-#include <linux/apple-mailbox.h>
#include <linux/bitfield.h>
#include <linux/bitmap.h>
#include <linux/completion.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
#include <linux/kernel.h>
-#include <linux/mailbox_client.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/soc/apple/rtkit.h>
#include <linux/workqueue.h>
+#include "mailbox.h"
#define APPLE_RTKIT_APP_ENDPOINT_START 0x20
#define APPLE_RTKIT_MAX_ENDPOINTS 0x100
@@ -28,10 +27,7 @@ struct apple_rtkit {
const struct apple_rtkit_ops *ops;
struct device *dev;
- const char *mbox_name;
- int mbox_idx;
- struct mbox_client mbox_cl;
- struct mbox_chan *mbox_chan;
+ struct apple_mbox *mbox;
struct completion epmap_completion;
struct completion iop_pwr_ack_completion;
diff --git a/drivers/soc/apple/rtkit.c b/drivers/soc/apple/rtkit.c
index 7c9b9f25bbc1..e6d940292c9f 100644
--- a/drivers/soc/apple/rtkit.c
+++ b/drivers/soc/apple/rtkit.c
@@ -72,11 +72,6 @@ enum {
#define APPLE_RTKIT_MIN_SUPPORTED_VERSION 11
#define APPLE_RTKIT_MAX_SUPPORTED_VERSION 12
-struct apple_rtkit_msg {
- struct completion *completion;
- struct apple_mbox_msg mbox_msg;
-};
-
struct apple_rtkit_rx_work {
struct apple_rtkit *rtk;
u8 ep;
@@ -550,12 +545,12 @@ static void apple_rtkit_rx_work(struct work_struct *work)
kfree(rtk_work);
}
-static void apple_rtkit_rx(struct mbox_client *cl, void *mssg)
+static void apple_rtkit_rx(struct apple_mbox *mbox, struct apple_mbox_msg msg,
+ void *cookie)
{
- struct apple_rtkit *rtk = container_of(cl, struct apple_rtkit, mbox_cl);
- struct apple_mbox_msg *msg = mssg;
+ struct apple_rtkit *rtk = cookie;
struct apple_rtkit_rx_work *work;
- u8 ep = msg->msg1;
+ u8 ep = msg.msg1;
/*
* The message was read from a MMIO FIFO and we have to make
@@ -571,7 +566,7 @@ static void apple_rtkit_rx(struct mbox_client *cl, void *mssg)
if (ep >= APPLE_RTKIT_APP_ENDPOINT_START &&
rtk->ops->recv_message_early &&
- rtk->ops->recv_message_early(rtk->cookie, ep, msg->msg0))
+ rtk->ops->recv_message_early(rtk->cookie, ep, msg.msg0))
return;
work = kzalloc(sizeof(*work), GFP_ATOMIC);
@@ -580,30 +575,18 @@ static void apple_rtkit_rx(struct mbox_client *cl, void *mssg)
work->rtk = rtk;
work->ep = ep;
- work->msg = msg->msg0;
+ work->msg = msg.msg0;
INIT_WORK(&work->work, apple_rtkit_rx_work);
queue_work(rtk->wq, &work->work);
}
-static void apple_rtkit_tx_done(struct mbox_client *cl, void *mssg, int r)
-{
- struct apple_rtkit_msg *msg =
- container_of(mssg, struct apple_rtkit_msg, mbox_msg);
-
- if (r == -ETIME)
- return;
-
- if (msg->completion)
- complete(msg->completion);
- kfree(msg);
-}
-
int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
struct completion *completion, bool atomic)
{
- struct apple_rtkit_msg *msg;
- int ret;
- gfp_t flags;
+ struct apple_mbox_msg msg = {
+ .msg0 = message,
+ .msg1 = ep,
+ };
if (rtk->crashed)
return -EINVAL;
@@ -611,19 +594,6 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
!apple_rtkit_is_running(rtk))
return -EINVAL;
- if (atomic)
- flags = GFP_ATOMIC;
- else
- flags = GFP_KERNEL;
-
- msg = kzalloc(sizeof(*msg), flags);
- if (!msg)
- return -ENOMEM;
-
- msg->mbox_msg.msg0 = message;
- msg->mbox_msg.msg1 = ep;
- msg->completion = completion;
-
/*
* The message will be sent with a MMIO write. We need the barrier
* here to ensure any previous writes to buffers are visible to the
@@ -631,19 +601,13 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
*/
dma_wmb();
- ret = mbox_send_message(rtk->mbox_chan, &msg->mbox_msg);
- if (ret < 0) {
- kfree(msg);
- return ret;
- }
-
- return 0;
+ return apple_mbox_send(rtk->mbox, msg, atomic);
}
EXPORT_SYMBOL_GPL(apple_rtkit_send_message);
int apple_rtkit_poll(struct apple_rtkit *rtk)
{
- return mbox_client_peek_data(rtk->mbox_chan);
+ return apple_mbox_poll(rtk->mbox);
}
EXPORT_SYMBOL_GPL(apple_rtkit_poll);
@@ -665,20 +629,6 @@ int apple_rtkit_start_ep(struct apple_rtkit *rtk, u8 endpoint)
}
EXPORT_SYMBOL_GPL(apple_rtkit_start_ep);
-static int apple_rtkit_request_mbox_chan(struct apple_rtkit *rtk)
-{
- if (rtk->mbox_name)
- rtk->mbox_chan = mbox_request_channel_byname(&rtk->mbox_cl,
- rtk->mbox_name);
- else
- rtk->mbox_chan =
- mbox_request_channel(&rtk->mbox_cl, rtk->mbox_idx);
-
- if (IS_ERR(rtk->mbox_chan))
- return PTR_ERR(rtk->mbox_chan);
- return 0;
-}
-
struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie,
const char *mbox_name, int mbox_idx,
const struct apple_rtkit_ops *ops)
@@ -704,13 +654,18 @@ struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie,
bitmap_zero(rtk->endpoints, APPLE_RTKIT_MAX_ENDPOINTS);
set_bit(APPLE_RTKIT_EP_MGMT, rtk->endpoints);
- rtk->mbox_name = mbox_name;
- rtk->mbox_idx = mbox_idx;
- rtk->mbox_cl.dev = dev;
- rtk->mbox_cl.tx_block = false;
- rtk->mbox_cl.knows_txdone = false;
- rtk->mbox_cl.rx_callback = &apple_rtkit_rx;
- rtk->mbox_cl.tx_done = &apple_rtkit_tx_done;
+ if (mbox_name)
+ rtk->mbox = apple_mbox_get_byname(dev, mbox_name);
+ else
+ rtk->mbox = apple_mbox_get(dev, mbox_idx);
+
+ if (IS_ERR(rtk->mbox)) {
+ ret = PTR_ERR(rtk->mbox);
+ goto free_rtk;
+ }
+
+ rtk->mbox->rx = apple_rtkit_rx;
+ rtk->mbox->cookie = rtk;
rtk->wq = alloc_ordered_workqueue("rtkit-%s", WQ_MEM_RECLAIM,
dev_name(rtk->dev));
@@ -719,7 +674,7 @@ struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie,
goto free_rtk;
}
- ret = apple_rtkit_request_mbox_chan(rtk);
+ ret = apple_mbox_start(rtk->mbox);
if (ret)
goto destroy_wq;
@@ -750,7 +705,7 @@ static int apple_rtkit_wait_for_completion(struct completion *c)
int apple_rtkit_reinit(struct apple_rtkit *rtk)
{
/* make sure we don't handle any messages while reinitializing */
- mbox_free_channel(rtk->mbox_chan);
+ apple_mbox_stop(rtk->mbox);
flush_workqueue(rtk->wq);
apple_rtkit_free_buffer(rtk, &rtk->ioreport_buffer);
@@ -774,7 +729,7 @@ int apple_rtkit_reinit(struct apple_rtkit *rtk)
rtk->iop_power_state = APPLE_RTKIT_PWR_STATE_OFF;
rtk->ap_power_state = APPLE_RTKIT_PWR_STATE_OFF;
- return apple_rtkit_request_mbox_chan(rtk);
+ return apple_mbox_start(rtk->mbox);
}
EXPORT_SYMBOL_GPL(apple_rtkit_reinit);
@@ -930,7 +885,7 @@ EXPORT_SYMBOL_GPL(apple_rtkit_wake);
void apple_rtkit_free(struct apple_rtkit *rtk)
{
- mbox_free_channel(rtk->mbox_chan);
+ apple_mbox_stop(rtk->mbox);
destroy_workqueue(rtk->wq);
apple_rtkit_free_buffer(rtk, &rtk->ioreport_buffer);
--
2.40.0
This driver is now orphaned and superseded by
drivers/soc/apple/mailbox.c.
Signed-off-by: Hector Martin <[email protected]>
---
MAINTAINERS | 2 -
drivers/mailbox/Kconfig | 12 --
drivers/mailbox/Makefile | 2 -
drivers/mailbox/apple-mailbox.c | 441 ----------------------------------------
include/linux/apple-mailbox.h | 19 --
5 files changed, 476 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..c115e0ad41da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1966,7 +1966,6 @@ F: drivers/i2c/busses/i2c-pasemi-platform.c
F: drivers/iommu/apple-dart.c
F: drivers/iommu/io-pgtable-dart.c
F: drivers/irqchip/irq-apple-aic.c
-F: drivers/mailbox/apple-mailbox.c
F: drivers/nvme/host/apple.c
F: drivers/nvmem/apple-efuses.c
F: drivers/pinctrl/pinctrl-apple-gpio.c
@@ -1974,7 +1973,6 @@ F: drivers/soc/apple/*
F: drivers/watchdog/apple_wdt.c
F: include/dt-bindings/interrupt-controller/apple-aic.h
F: include/dt-bindings/pinctrl/apple.h
-F: include/linux/apple-mailbox.h
F: include/linux/soc/apple/*
ARM/APPLE MACHINE SOUND DRIVERS
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 1495965bc394..73952108cc52 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -8,18 +8,6 @@ menuconfig MAILBOX
if MAILBOX
-config APPLE_MAILBOX
- tristate "Apple Mailbox driver"
- depends on ARCH_APPLE || (ARM64 && COMPILE_TEST)
- default ARCH_APPLE
- help
- Apple SoCs have various co-processors required for certain
- peripherals to work (NVMe, display controller, etc.). This
- driver adds support for the mailbox controller used to
- communicate with those.
-
- Say Y here if you have a Apple SoC.
-
config ARM_MHU
tristate "ARM MHU Mailbox"
depends on ARM_AMBA
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index fc9376117111..18793e6caa2f 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -60,5 +60,3 @@ obj-$(CONFIG_SUN6I_MSGBOX) += sun6i-msgbox.o
obj-$(CONFIG_SPRD_MBOX) += sprd-mailbox.o
obj-$(CONFIG_QCOM_IPCC) += qcom-ipcc.o
-
-obj-$(CONFIG_APPLE_MAILBOX) += apple-mailbox.o
diff --git a/drivers/mailbox/apple-mailbox.c b/drivers/mailbox/apple-mailbox.c
deleted file mode 100644
index 2a3e8d8ff8b5..000000000000
--- a/drivers/mailbox/apple-mailbox.c
+++ /dev/null
@@ -1,441 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only OR MIT
-/*
- * Apple mailbox driver
- *
- * Copyright (C) 2021 The Asahi Linux Contributors
- *
- * This driver adds support for two mailbox variants (called ASC and M3 by
- * Apple) found in Apple SoCs such as the M1. It consists of two FIFOs used to
- * exchange 64+32 bit messages between the main CPU and a co-processor.
- * Various coprocessors implement different IPC protocols based on these simple
- * messages and shared memory buffers.
- *
- * Both the main CPU and the co-processor see the same set of registers but
- * the first FIFO (A2I) is always used to transfer messages from the application
- * processor (us) to the I/O processor and the second one (I2A) for the
- * other direction.
- */
-
-#include <linux/apple-mailbox.h>
-#include <linux/delay.h>
-#include <linux/device.h>
-#include <linux/gfp.h>
-#include <linux/interrupt.h>
-#include <linux/io.h>
-#include <linux/mailbox_controller.h>
-#include <linux/module.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-#include <linux/spinlock.h>
-#include <linux/types.h>
-
-#define APPLE_ASC_MBOX_CONTROL_FULL BIT(16)
-#define APPLE_ASC_MBOX_CONTROL_EMPTY BIT(17)
-
-#define APPLE_ASC_MBOX_A2I_CONTROL 0x110
-#define APPLE_ASC_MBOX_A2I_SEND0 0x800
-#define APPLE_ASC_MBOX_A2I_SEND1 0x808
-#define APPLE_ASC_MBOX_A2I_RECV0 0x810
-#define APPLE_ASC_MBOX_A2I_RECV1 0x818
-
-#define APPLE_ASC_MBOX_I2A_CONTROL 0x114
-#define APPLE_ASC_MBOX_I2A_SEND0 0x820
-#define APPLE_ASC_MBOX_I2A_SEND1 0x828
-#define APPLE_ASC_MBOX_I2A_RECV0 0x830
-#define APPLE_ASC_MBOX_I2A_RECV1 0x838
-
-#define APPLE_M3_MBOX_CONTROL_FULL BIT(16)
-#define APPLE_M3_MBOX_CONTROL_EMPTY BIT(17)
-
-#define APPLE_M3_MBOX_A2I_CONTROL 0x50
-#define APPLE_M3_MBOX_A2I_SEND0 0x60
-#define APPLE_M3_MBOX_A2I_SEND1 0x68
-#define APPLE_M3_MBOX_A2I_RECV0 0x70
-#define APPLE_M3_MBOX_A2I_RECV1 0x78
-
-#define APPLE_M3_MBOX_I2A_CONTROL 0x80
-#define APPLE_M3_MBOX_I2A_SEND0 0x90
-#define APPLE_M3_MBOX_I2A_SEND1 0x98
-#define APPLE_M3_MBOX_I2A_RECV0 0xa0
-#define APPLE_M3_MBOX_I2A_RECV1 0xa8
-
-#define APPLE_M3_MBOX_IRQ_ENABLE 0x48
-#define APPLE_M3_MBOX_IRQ_ACK 0x4c
-#define APPLE_M3_MBOX_IRQ_A2I_EMPTY BIT(0)
-#define APPLE_M3_MBOX_IRQ_A2I_NOT_EMPTY BIT(1)
-#define APPLE_M3_MBOX_IRQ_I2A_EMPTY BIT(2)
-#define APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY BIT(3)
-
-#define APPLE_MBOX_MSG1_OUTCNT GENMASK(56, 52)
-#define APPLE_MBOX_MSG1_INCNT GENMASK(51, 48)
-#define APPLE_MBOX_MSG1_OUTPTR GENMASK(47, 44)
-#define APPLE_MBOX_MSG1_INPTR GENMASK(43, 40)
-#define APPLE_MBOX_MSG1_MSG GENMASK(31, 0)
-
-struct apple_mbox_hw {
- unsigned int control_full;
- unsigned int control_empty;
-
- unsigned int a2i_control;
- unsigned int a2i_send0;
- unsigned int a2i_send1;
-
- unsigned int i2a_control;
- unsigned int i2a_recv0;
- unsigned int i2a_recv1;
-
- bool has_irq_controls;
- unsigned int irq_enable;
- unsigned int irq_ack;
- unsigned int irq_bit_recv_not_empty;
- unsigned int irq_bit_send_empty;
-};
-
-struct apple_mbox {
- void __iomem *regs;
- const struct apple_mbox_hw *hw;
-
- int irq_recv_not_empty;
- int irq_send_empty;
-
- struct mbox_chan chan;
-
- struct device *dev;
- struct mbox_controller controller;
- spinlock_t rx_lock;
-};
-
-static const struct of_device_id apple_mbox_of_match[];
-
-static bool apple_mbox_hw_can_send(struct apple_mbox *apple_mbox)
-{
- u32 mbox_ctrl =
- readl_relaxed(apple_mbox->regs + apple_mbox->hw->a2i_control);
-
- return !(mbox_ctrl & apple_mbox->hw->control_full);
-}
-
-static bool apple_mbox_hw_send_empty(struct apple_mbox *apple_mbox)
-{
- u32 mbox_ctrl =
- readl_relaxed(apple_mbox->regs + apple_mbox->hw->a2i_control);
-
- return mbox_ctrl & apple_mbox->hw->control_empty;
-}
-
-static int apple_mbox_hw_send(struct apple_mbox *apple_mbox,
- struct apple_mbox_msg *msg)
-{
- if (!apple_mbox_hw_can_send(apple_mbox))
- return -EBUSY;
-
- dev_dbg(apple_mbox->dev, "> TX %016llx %08x\n", msg->msg0, msg->msg1);
-
- writeq_relaxed(msg->msg0, apple_mbox->regs + apple_mbox->hw->a2i_send0);
- writeq_relaxed(FIELD_PREP(APPLE_MBOX_MSG1_MSG, msg->msg1),
- apple_mbox->regs + apple_mbox->hw->a2i_send1);
-
- return 0;
-}
-
-static bool apple_mbox_hw_can_recv(struct apple_mbox *apple_mbox)
-{
- u32 mbox_ctrl =
- readl_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_control);
-
- return !(mbox_ctrl & apple_mbox->hw->control_empty);
-}
-
-static int apple_mbox_hw_recv(struct apple_mbox *apple_mbox,
- struct apple_mbox_msg *msg)
-{
- if (!apple_mbox_hw_can_recv(apple_mbox))
- return -ENOMSG;
-
- msg->msg0 = readq_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_recv0);
- msg->msg1 = FIELD_GET(
- APPLE_MBOX_MSG1_MSG,
- readq_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_recv1));
-
- dev_dbg(apple_mbox->dev, "< RX %016llx %08x\n", msg->msg0, msg->msg1);
-
- return 0;
-}
-
-static int apple_mbox_chan_send_data(struct mbox_chan *chan, void *data)
-{
- struct apple_mbox *apple_mbox = chan->con_priv;
- struct apple_mbox_msg *msg = data;
- int ret;
-
- ret = apple_mbox_hw_send(apple_mbox, msg);
- if (ret)
- return ret;
-
- /*
- * The interrupt is level triggered and will keep firing as long as the
- * FIFO is empty. It will also keep firing if the FIFO was empty
- * at any point in the past until it has been acknowledged at the
- * mailbox level. By acknowledging it here we can ensure that we will
- * only get the interrupt once the FIFO has been cleared again.
- * If the FIFO is already empty before the ack it will fire again
- * immediately after the ack.
- */
- if (apple_mbox->hw->has_irq_controls) {
- writel_relaxed(apple_mbox->hw->irq_bit_send_empty,
- apple_mbox->regs + apple_mbox->hw->irq_ack);
- }
- enable_irq(apple_mbox->irq_send_empty);
-
- return 0;
-}
-
-static irqreturn_t apple_mbox_send_empty_irq(int irq, void *data)
-{
- struct apple_mbox *apple_mbox = data;
-
- /*
- * We don't need to acknowledge the interrupt at the mailbox level
- * here even if supported by the hardware. It will keep firing but that
- * doesn't matter since it's disabled at the main interrupt controller.
- * apple_mbox_chan_send_data will acknowledge it before enabling
- * it at the main controller again.
- */
- disable_irq_nosync(apple_mbox->irq_send_empty);
- mbox_chan_txdone(&apple_mbox->chan, 0);
- return IRQ_HANDLED;
-}
-
-static int apple_mbox_poll(struct apple_mbox *apple_mbox)
-{
- struct apple_mbox_msg msg;
- int ret = 0;
-
- while (apple_mbox_hw_recv(apple_mbox, &msg) == 0) {
- mbox_chan_received_data(&apple_mbox->chan, (void *)&msg);
- ret++;
- }
-
- /*
- * The interrupt will keep firing even if there are no more messages
- * unless we also acknowledge it at the mailbox level here.
- * There's no race if a message comes in between the check in the while
- * loop above and the ack below: If a new messages arrives inbetween
- * those two the interrupt will just fire again immediately after the
- * ack since it's level triggered.
- */
- if (apple_mbox->hw->has_irq_controls) {
- writel_relaxed(apple_mbox->hw->irq_bit_recv_not_empty,
- apple_mbox->regs + apple_mbox->hw->irq_ack);
- }
-
- return ret;
-}
-
-static irqreturn_t apple_mbox_recv_irq(int irq, void *data)
-{
- struct apple_mbox *apple_mbox = data;
-
- spin_lock(&apple_mbox->rx_lock);
- apple_mbox_poll(apple_mbox);
- spin_unlock(&apple_mbox->rx_lock);
-
- return IRQ_HANDLED;
-}
-
-static bool apple_mbox_chan_peek_data(struct mbox_chan *chan)
-{
- struct apple_mbox *apple_mbox = chan->con_priv;
- unsigned long flags;
- int ret;
-
- spin_lock_irqsave(&apple_mbox->rx_lock, flags);
- ret = apple_mbox_poll(apple_mbox);
- spin_unlock_irqrestore(&apple_mbox->rx_lock, flags);
-
- return ret > 0;
-}
-
-static int apple_mbox_chan_flush(struct mbox_chan *chan, unsigned long timeout)
-{
- struct apple_mbox *apple_mbox = chan->con_priv;
- unsigned long deadline = jiffies + msecs_to_jiffies(timeout);
-
- while (time_before(jiffies, deadline)) {
- if (apple_mbox_hw_send_empty(apple_mbox)) {
- mbox_chan_txdone(&apple_mbox->chan, 0);
- return 0;
- }
-
- udelay(1);
- }
-
- return -ETIME;
-}
-
-static int apple_mbox_chan_startup(struct mbox_chan *chan)
-{
- struct apple_mbox *apple_mbox = chan->con_priv;
-
- /*
- * Only some variants of this mailbox HW provide interrupt control
- * at the mailbox level. We therefore need to handle enabling/disabling
- * interrupts at the main interrupt controller anyway for hardware that
- * doesn't. Just always keep the interrupts we care about enabled at
- * the mailbox level so that both hardware revisions behave almost
- * the same.
- */
- if (apple_mbox->hw->has_irq_controls) {
- writel_relaxed(apple_mbox->hw->irq_bit_recv_not_empty |
- apple_mbox->hw->irq_bit_send_empty,
- apple_mbox->regs + apple_mbox->hw->irq_enable);
- }
-
- enable_irq(apple_mbox->irq_recv_not_empty);
- return 0;
-}
-
-static void apple_mbox_chan_shutdown(struct mbox_chan *chan)
-{
- struct apple_mbox *apple_mbox = chan->con_priv;
-
- disable_irq(apple_mbox->irq_recv_not_empty);
-}
-
-static const struct mbox_chan_ops apple_mbox_ops = {
- .send_data = apple_mbox_chan_send_data,
- .peek_data = apple_mbox_chan_peek_data,
- .flush = apple_mbox_chan_flush,
- .startup = apple_mbox_chan_startup,
- .shutdown = apple_mbox_chan_shutdown,
-};
-
-static struct mbox_chan *apple_mbox_of_xlate(struct mbox_controller *mbox,
- const struct of_phandle_args *args)
-{
- if (args->args_count != 0)
- return ERR_PTR(-EINVAL);
-
- return &mbox->chans[0];
-}
-
-static int apple_mbox_probe(struct platform_device *pdev)
-{
- int ret;
- const struct of_device_id *match;
- char *irqname;
- struct apple_mbox *mbox;
- struct device *dev = &pdev->dev;
-
- match = of_match_node(apple_mbox_of_match, pdev->dev.of_node);
- if (!match)
- return -EINVAL;
- if (!match->data)
- return -EINVAL;
-
- mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
- if (!mbox)
- return -ENOMEM;
- platform_set_drvdata(pdev, mbox);
-
- mbox->dev = dev;
- mbox->regs = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(mbox->regs))
- return PTR_ERR(mbox->regs);
-
- mbox->hw = match->data;
- mbox->irq_recv_not_empty =
- platform_get_irq_byname(pdev, "recv-not-empty");
- if (mbox->irq_recv_not_empty < 0)
- return -ENODEV;
-
- mbox->irq_send_empty = platform_get_irq_byname(pdev, "send-empty");
- if (mbox->irq_send_empty < 0)
- return -ENODEV;
-
- mbox->controller.dev = mbox->dev;
- mbox->controller.num_chans = 1;
- mbox->controller.chans = &mbox->chan;
- mbox->controller.ops = &apple_mbox_ops;
- mbox->controller.txdone_irq = true;
- mbox->controller.of_xlate = apple_mbox_of_xlate;
- mbox->chan.con_priv = mbox;
- spin_lock_init(&mbox->rx_lock);
-
- irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-recv", dev_name(dev));
- if (!irqname)
- return -ENOMEM;
-
- ret = devm_request_threaded_irq(dev, mbox->irq_recv_not_empty, NULL,
- apple_mbox_recv_irq,
- IRQF_NO_AUTOEN | IRQF_ONESHOT, irqname,
- mbox);
- if (ret)
- return ret;
-
- irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-send", dev_name(dev));
- if (!irqname)
- return -ENOMEM;
-
- ret = devm_request_irq(dev, mbox->irq_send_empty,
- apple_mbox_send_empty_irq, IRQF_NO_AUTOEN,
- irqname, mbox);
- if (ret)
- return ret;
-
- return devm_mbox_controller_register(dev, &mbox->controller);
-}
-
-static const struct apple_mbox_hw apple_mbox_asc_hw = {
- .control_full = APPLE_ASC_MBOX_CONTROL_FULL,
- .control_empty = APPLE_ASC_MBOX_CONTROL_EMPTY,
-
- .a2i_control = APPLE_ASC_MBOX_A2I_CONTROL,
- .a2i_send0 = APPLE_ASC_MBOX_A2I_SEND0,
- .a2i_send1 = APPLE_ASC_MBOX_A2I_SEND1,
-
- .i2a_control = APPLE_ASC_MBOX_I2A_CONTROL,
- .i2a_recv0 = APPLE_ASC_MBOX_I2A_RECV0,
- .i2a_recv1 = APPLE_ASC_MBOX_I2A_RECV1,
-
- .has_irq_controls = false,
-};
-
-static const struct apple_mbox_hw apple_mbox_m3_hw = {
- .control_full = APPLE_M3_MBOX_CONTROL_FULL,
- .control_empty = APPLE_M3_MBOX_CONTROL_EMPTY,
-
- .a2i_control = APPLE_M3_MBOX_A2I_CONTROL,
- .a2i_send0 = APPLE_M3_MBOX_A2I_SEND0,
- .a2i_send1 = APPLE_M3_MBOX_A2I_SEND1,
-
- .i2a_control = APPLE_M3_MBOX_I2A_CONTROL,
- .i2a_recv0 = APPLE_M3_MBOX_I2A_RECV0,
- .i2a_recv1 = APPLE_M3_MBOX_I2A_RECV1,
-
- .has_irq_controls = true,
- .irq_enable = APPLE_M3_MBOX_IRQ_ENABLE,
- .irq_ack = APPLE_M3_MBOX_IRQ_ACK,
- .irq_bit_recv_not_empty = APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY,
- .irq_bit_send_empty = APPLE_M3_MBOX_IRQ_A2I_EMPTY,
-};
-
-static const struct of_device_id apple_mbox_of_match[] = {
- { .compatible = "apple,asc-mailbox-v4", .data = &apple_mbox_asc_hw },
- { .compatible = "apple,m3-mailbox-v2", .data = &apple_mbox_m3_hw },
- {}
-};
-MODULE_DEVICE_TABLE(of, apple_mbox_of_match);
-
-static struct platform_driver apple_mbox_driver = {
- .driver = {
- .name = "apple-mailbox",
- .of_match_table = apple_mbox_of_match,
- },
- .probe = apple_mbox_probe,
-};
-module_platform_driver(apple_mbox_driver);
-
-MODULE_LICENSE("Dual MIT/GPL");
-MODULE_AUTHOR("Sven Peter <[email protected]>");
-MODULE_DESCRIPTION("Apple Mailbox driver");
diff --git a/include/linux/apple-mailbox.h b/include/linux/apple-mailbox.h
deleted file mode 100644
index 720fbb70294a..000000000000
--- a/include/linux/apple-mailbox.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
-/*
- * Apple mailbox message format
- *
- * Copyright (C) 2021 The Asahi Linux Contributors
- */
-
-#ifndef _LINUX_APPLE_MAILBOX_H_
-#define _LINUX_APPLE_MAILBOX_H_
-
-#include <linux/types.h>
-
-/* encodes a single 96bit message sent over the single channel */
-struct apple_mbox_msg {
- u64 msg0;
- u32 msg1;
-};
-
-#endif
--
2.40.0
With the original owner of APPLE_MAILBOX removed, let's rename the new
APPLE_MBOX to the old name. This avoids .config churn for downstream
users, and leaves us with an identical config symbol and module name as
before.
Signed-off-by: Hector Martin <[email protected]>
---
drivers/soc/apple/Kconfig | 5 ++---
drivers/soc/apple/Makefile | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
index d0e29bbd8c6f..c5203c388bf4 100644
--- a/drivers/soc/apple/Kconfig
+++ b/drivers/soc/apple/Kconfig
@@ -17,11 +17,10 @@ config APPLE_PMGR_PWRSTATE
controls for SoC devices. This driver manages them through the
generic power domain framework, and also provides reset support.
-config APPLE_MBOX
+config APPLE_MAILBOX
tristate "Apple SoC mailboxes"
depends on PM
depends on ARCH_APPLE || (64BIT && COMPILE_TEST)
- depends on !APPLE_MAILBOX
default ARCH_APPLE
help
Apple SoCs have various co-processors required for certain
@@ -33,7 +32,7 @@ config APPLE_MBOX
config APPLE_RTKIT
tristate "Apple RTKit co-processor IPC protocol"
- depends on APPLE_MBOX
+ depends on APPLE_MAILBOX
depends on ARCH_APPLE || COMPILE_TEST
default ARCH_APPLE
help
diff --git a/drivers/soc/apple/Makefile b/drivers/soc/apple/Makefile
index e52edf6a73da..20feee6f3943 100644
--- a/drivers/soc/apple/Makefile
+++ b/drivers/soc/apple/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_APPLE_PMGR_PWRSTATE) += apple-pmgr-pwrstate.o
-obj-$(CONFIG_APPLE_MBOX) += apple-mailbox.o
+obj-$(CONFIG_APPLE_MAILBOX) += apple-mailbox.o
apple-mailbox-y = mailbox.o
obj-$(CONFIG_APPLE_RTKIT) += apple-rtkit.o
--
2.40.0
This new driver is based on the existing apple-mailbox driver, but
replaces the usage of the mailbox subsystem with directly exported
symbols.
As part of this refactor, this adds support for using the hardware FIFOs
(not supported in mailbox) and implicitly fixes a bunch of bugs caused
by bad interactions with the mailbox subsystem. It also adds runtime-PM
support.
The new config symbol is APPLE_MBOX, while the module name remains
identical ("apple-mailbox"). The configs are mutually exclusive in
Kconfig, to avoid conflicts.
Signed-off-by: Hector Martin <[email protected]>
---
drivers/soc/apple/Kconfig | 14 ++
drivers/soc/apple/Makefile | 3 +
drivers/soc/apple/mailbox.c | 434 ++++++++++++++++++++++++++++++++++++++++++++
drivers/soc/apple/mailbox.h | 48 +++++
4 files changed, 499 insertions(+)
diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
index a1596fefacff..caa2cf09ff7a 100644
--- a/drivers/soc/apple/Kconfig
+++ b/drivers/soc/apple/Kconfig
@@ -17,6 +17,20 @@ config APPLE_PMGR_PWRSTATE
controls for SoC devices. This driver manages them through the
generic power domain framework, and also provides reset support.
+config APPLE_MBOX
+ tristate "Apple SoC mailboxes"
+ depends on PM
+ depends on ARCH_APPLE || (64BIT && COMPILE_TEST)
+ depends on !APPLE_MAILBOX
+ default ARCH_APPLE
+ help
+ Apple SoCs have various co-processors required for certain
+ peripherals to work (NVMe, display controller, etc.). This
+ driver adds support for the mailbox controller used to
+ communicate with those.
+
+ Say Y here if you have an Apple SoC.
+
config APPLE_RTKIT
tristate "Apple RTKit co-processor IPC protocol"
depends on MAILBOX
diff --git a/drivers/soc/apple/Makefile b/drivers/soc/apple/Makefile
index e293770cf66d..e52edf6a73da 100644
--- a/drivers/soc/apple/Makefile
+++ b/drivers/soc/apple/Makefile
@@ -1,6 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_APPLE_PMGR_PWRSTATE) += apple-pmgr-pwrstate.o
+obj-$(CONFIG_APPLE_MBOX) += apple-mailbox.o
+apple-mailbox-y = mailbox.o
+
obj-$(CONFIG_APPLE_RTKIT) += apple-rtkit.o
apple-rtkit-y = rtkit.o rtkit-crashlog.o
diff --git a/drivers/soc/apple/mailbox.c b/drivers/soc/apple/mailbox.c
new file mode 100644
index 000000000000..7bdebafa6e83
--- /dev/null
+++ b/drivers/soc/apple/mailbox.c
@@ -0,0 +1,434 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Apple mailbox driver
+ *
+ * Copyright The Asahi Linux Contributors
+ *
+ * This driver adds support for two mailbox variants (called ASC and M3 by
+ * Apple) found in Apple SoCs such as the M1. It consists of two FIFOs used to
+ * exchange 64+32 bit messages between the main CPU and a co-processor.
+ * Various coprocessors implement different IPC protocols based on these simple
+ * messages and shared memory buffers.
+ *
+ * Both the main CPU and the co-processor see the same set of registers but
+ * the first FIFO (A2I) is always used to transfer messages from the application
+ * processor (us) to the I/O processor and the second one (I2A) for the
+ * other direction.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_runtime.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+#include "mailbox.h"
+
+#define APPLE_ASC_MBOX_CONTROL_FULL BIT(16)
+#define APPLE_ASC_MBOX_CONTROL_EMPTY BIT(17)
+
+#define APPLE_ASC_MBOX_A2I_CONTROL 0x110
+#define APPLE_ASC_MBOX_A2I_SEND0 0x800
+#define APPLE_ASC_MBOX_A2I_SEND1 0x808
+#define APPLE_ASC_MBOX_A2I_RECV0 0x810
+#define APPLE_ASC_MBOX_A2I_RECV1 0x818
+
+#define APPLE_ASC_MBOX_I2A_CONTROL 0x114
+#define APPLE_ASC_MBOX_I2A_SEND0 0x820
+#define APPLE_ASC_MBOX_I2A_SEND1 0x828
+#define APPLE_ASC_MBOX_I2A_RECV0 0x830
+#define APPLE_ASC_MBOX_I2A_RECV1 0x838
+
+#define APPLE_M3_MBOX_CONTROL_FULL BIT(16)
+#define APPLE_M3_MBOX_CONTROL_EMPTY BIT(17)
+
+#define APPLE_M3_MBOX_A2I_CONTROL 0x50
+#define APPLE_M3_MBOX_A2I_SEND0 0x60
+#define APPLE_M3_MBOX_A2I_SEND1 0x68
+#define APPLE_M3_MBOX_A2I_RECV0 0x70
+#define APPLE_M3_MBOX_A2I_RECV1 0x78
+
+#define APPLE_M3_MBOX_I2A_CONTROL 0x80
+#define APPLE_M3_MBOX_I2A_SEND0 0x90
+#define APPLE_M3_MBOX_I2A_SEND1 0x98
+#define APPLE_M3_MBOX_I2A_RECV0 0xa0
+#define APPLE_M3_MBOX_I2A_RECV1 0xa8
+
+#define APPLE_M3_MBOX_IRQ_ENABLE 0x48
+#define APPLE_M3_MBOX_IRQ_ACK 0x4c
+#define APPLE_M3_MBOX_IRQ_A2I_EMPTY BIT(0)
+#define APPLE_M3_MBOX_IRQ_A2I_NOT_EMPTY BIT(1)
+#define APPLE_M3_MBOX_IRQ_I2A_EMPTY BIT(2)
+#define APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY BIT(3)
+
+#define APPLE_MBOX_MSG1_OUTCNT GENMASK(56, 52)
+#define APPLE_MBOX_MSG1_INCNT GENMASK(51, 48)
+#define APPLE_MBOX_MSG1_OUTPTR GENMASK(47, 44)
+#define APPLE_MBOX_MSG1_INPTR GENMASK(43, 40)
+#define APPLE_MBOX_MSG1_MSG GENMASK(31, 0)
+
+#define APPLE_MBOX_TX_TIMEOUT 500
+
+struct apple_mbox_hw {
+ unsigned int control_full;
+ unsigned int control_empty;
+
+ unsigned int a2i_control;
+ unsigned int a2i_send0;
+ unsigned int a2i_send1;
+
+ unsigned int i2a_control;
+ unsigned int i2a_recv0;
+ unsigned int i2a_recv1;
+
+ bool has_irq_controls;
+ unsigned int irq_enable;
+ unsigned int irq_ack;
+ unsigned int irq_bit_recv_not_empty;
+ unsigned int irq_bit_send_empty;
+};
+
+int apple_mbox_send(struct apple_mbox *mbox, const struct apple_mbox_msg msg,
+ bool atomic)
+{
+ unsigned long flags;
+ int ret;
+ u32 mbox_ctrl;
+ long t;
+
+ spin_lock_irqsave(&mbox->tx_lock, flags);
+ mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->a2i_control);
+
+ while (mbox_ctrl & mbox->hw->control_full) {
+ if (atomic) {
+ ret = readl_poll_timeout_atomic(
+ mbox->regs + mbox->hw->a2i_control, mbox_ctrl,
+ !(mbox_ctrl & mbox->hw->control_full), 100,
+ APPLE_MBOX_TX_TIMEOUT * 1000);
+
+ if (ret) {
+ spin_unlock_irqrestore(&mbox->tx_lock, flags);
+ return ret;
+ }
+
+ break;
+ }
+ /*
+ * The interrupt is level triggered and will keep firing as long as the
+ * FIFO is empty. It will also keep firing if the FIFO was empty
+ * at any point in the past until it has been acknowledged at the
+ * mailbox level. By acknowledging it here we can ensure that we will
+ * only get the interrupt once the FIFO has been cleared again.
+ * If the FIFO is already empty before the ack it will fire again
+ * immediately after the ack.
+ */
+ if (mbox->hw->has_irq_controls) {
+ writel_relaxed(mbox->hw->irq_bit_send_empty,
+ mbox->regs + mbox->hw->irq_ack);
+ }
+ enable_irq(mbox->irq_send_empty);
+ reinit_completion(&mbox->tx_empty);
+ spin_unlock_irqrestore(&mbox->tx_lock, flags);
+
+ t = wait_for_completion_interruptible_timeout(
+ &mbox->tx_empty,
+ msecs_to_jiffies(APPLE_MBOX_TX_TIMEOUT));
+ if (t < 0)
+ return t;
+ else if (t == 0)
+ return -ETIMEDOUT;
+
+ spin_lock_irqsave(&mbox->tx_lock, flags);
+ mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->a2i_control);
+ }
+
+ writeq_relaxed(msg.msg0, mbox->regs + mbox->hw->a2i_send0);
+ writeq_relaxed(FIELD_PREP(APPLE_MBOX_MSG1_MSG, msg.msg1),
+ mbox->regs + mbox->hw->a2i_send1);
+
+ spin_unlock_irqrestore(&mbox->tx_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(apple_mbox_send);
+
+static irqreturn_t apple_mbox_send_empty_irq(int irq, void *data)
+{
+ struct apple_mbox *mbox = data;
+
+ /*
+ * We don't need to acknowledge the interrupt at the mailbox level
+ * here even if supported by the hardware. It will keep firing but that
+ * doesn't matter since it's disabled at the main interrupt controller.
+ * apple_mbox_send will acknowledge it before enabling
+ * it at the main controller again.
+ */
+ spin_lock(&mbox->tx_lock);
+ disable_irq_nosync(mbox->irq_send_empty);
+ complete(&mbox->tx_empty);
+ spin_unlock(&mbox->tx_lock);
+
+ return IRQ_HANDLED;
+}
+
+static int apple_mbox_poll_locked(struct apple_mbox *mbox)
+{
+ struct apple_mbox_msg msg;
+ int ret = 0;
+
+ u32 mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->i2a_control);
+
+ while (!(mbox_ctrl & mbox->hw->control_empty)) {
+ msg.msg0 = readq_relaxed(mbox->regs + mbox->hw->i2a_recv0);
+ msg.msg1 = FIELD_GET(
+ APPLE_MBOX_MSG1_MSG,
+ readq_relaxed(mbox->regs + mbox->hw->i2a_recv1));
+
+ mbox->rx(mbox, msg, mbox->cookie);
+ ret++;
+ mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->i2a_control);
+ }
+
+ /*
+ * The interrupt will keep firing even if there are no more messages
+ * unless we also acknowledge it at the mailbox level here.
+ * There's no race if a message comes in between the check in the while
+ * loop above and the ack below: If a new messages arrives inbetween
+ * those two the interrupt will just fire again immediately after the
+ * ack since it's level triggered.
+ */
+ if (mbox->hw->has_irq_controls) {
+ writel_relaxed(mbox->hw->irq_bit_recv_not_empty,
+ mbox->regs + mbox->hw->irq_ack);
+ }
+
+ return ret;
+}
+
+static irqreturn_t apple_mbox_recv_irq(int irq, void *data)
+{
+ struct apple_mbox *mbox = data;
+
+ spin_lock(&mbox->rx_lock);
+ apple_mbox_poll_locked(mbox);
+ spin_unlock(&mbox->rx_lock);
+
+ return IRQ_HANDLED;
+}
+
+int apple_mbox_poll(struct apple_mbox *mbox)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&mbox->rx_lock, flags);
+ ret = apple_mbox_poll_locked(mbox);
+ spin_unlock_irqrestore(&mbox->rx_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(apple_mbox_poll);
+
+int apple_mbox_start(struct apple_mbox *mbox)
+{
+ int ret;
+
+ if (mbox->active)
+ return 0;
+
+ ret = pm_runtime_resume_and_get(mbox->dev);
+ if (ret)
+ return ret;
+
+ /*
+ * Only some variants of this mailbox HW provide interrupt control
+ * at the mailbox level. We therefore need to handle enabling/disabling
+ * interrupts at the main interrupt controller anyway for hardware that
+ * doesn't. Just always keep the interrupts we care about enabled at
+ * the mailbox level so that both hardware revisions behave almost
+ * the same.
+ */
+ if (mbox->hw->has_irq_controls) {
+ writel_relaxed(mbox->hw->irq_bit_recv_not_empty |
+ mbox->hw->irq_bit_send_empty,
+ mbox->regs + mbox->hw->irq_enable);
+ }
+
+ enable_irq(mbox->irq_recv_not_empty);
+ mbox->active = true;
+ return 0;
+}
+EXPORT_SYMBOL(apple_mbox_start);
+
+void apple_mbox_stop(struct apple_mbox *mbox)
+{
+ if (!mbox->active)
+ return;
+
+ mbox->active = false;
+ disable_irq(mbox->irq_recv_not_empty);
+ pm_runtime_mark_last_busy(mbox->dev);
+ pm_runtime_put_autosuspend(mbox->dev);
+}
+EXPORT_SYMBOL(apple_mbox_stop);
+
+struct apple_mbox *apple_mbox_get(struct device *dev, int index)
+{
+ struct of_phandle_args args;
+ struct platform_device *pdev;
+ struct apple_mbox *mbox;
+ int ret;
+
+ ret = of_parse_phandle_with_args(dev->of_node, "mboxes", "#mbox-cells",
+ index, &args);
+ if (ret || !args.np)
+ return ERR_PTR(ret);
+
+ pdev = of_find_device_by_node(args.np);
+ of_node_put(args.np);
+
+ if (!pdev)
+ return ERR_PTR(EPROBE_DEFER);
+
+ mbox = platform_get_drvdata(pdev);
+ if (!mbox)
+ return ERR_PTR(EPROBE_DEFER);
+
+ if (!device_link_add(dev, &pdev->dev, DL_FLAG_AUTOREMOVE_CONSUMER))
+ return ERR_PTR(ENODEV);
+
+ return mbox;
+}
+EXPORT_SYMBOL(apple_mbox_get);
+
+struct apple_mbox *apple_mbox_get_byname(struct device *dev, const char *name)
+{
+ int index;
+
+ index = of_property_match_string(dev->of_node, "mbox-names", name);
+ if (index < 0)
+ return ERR_PTR(index);
+
+ return apple_mbox_get(dev, index);
+}
+EXPORT_SYMBOL(apple_mbox_get_byname);
+
+static int apple_mbox_probe(struct platform_device *pdev)
+{
+ int ret;
+ char *irqname;
+ struct apple_mbox *mbox;
+ struct device *dev = &pdev->dev;
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ mbox->dev = &pdev->dev;
+ mbox->hw = of_device_get_match_data(dev);
+ if (!mbox->hw)
+ return -EINVAL;
+
+ mbox->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(mbox->regs))
+ return PTR_ERR(mbox->regs);
+
+ mbox->irq_recv_not_empty =
+ platform_get_irq_byname(pdev, "recv-not-empty");
+ if (mbox->irq_recv_not_empty < 0)
+ return -ENODEV;
+
+ mbox->irq_send_empty = platform_get_irq_byname(pdev, "send-empty");
+ if (mbox->irq_send_empty < 0)
+ return -ENODEV;
+
+ spin_lock_init(&mbox->rx_lock);
+ spin_lock_init(&mbox->tx_lock);
+ init_completion(&mbox->tx_empty);
+
+ irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-recv", dev_name(dev));
+ if (!irqname)
+ return -ENOMEM;
+
+ ret = devm_request_irq(dev, mbox->irq_recv_not_empty,
+ apple_mbox_recv_irq,
+ IRQF_NO_AUTOEN | IRQF_NO_SUSPEND, irqname, mbox);
+ if (ret)
+ return ret;
+
+ irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-send", dev_name(dev));
+ if (!irqname)
+ return -ENOMEM;
+
+ ret = devm_request_irq(dev, mbox->irq_send_empty,
+ apple_mbox_send_empty_irq,
+ IRQF_NO_AUTOEN | IRQF_NO_SUSPEND, irqname, mbox);
+ if (ret)
+ return ret;
+
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, mbox);
+ return 0;
+}
+
+static const struct apple_mbox_hw apple_mbox_asc_hw = {
+ .control_full = APPLE_ASC_MBOX_CONTROL_FULL,
+ .control_empty = APPLE_ASC_MBOX_CONTROL_EMPTY,
+
+ .a2i_control = APPLE_ASC_MBOX_A2I_CONTROL,
+ .a2i_send0 = APPLE_ASC_MBOX_A2I_SEND0,
+ .a2i_send1 = APPLE_ASC_MBOX_A2I_SEND1,
+
+ .i2a_control = APPLE_ASC_MBOX_I2A_CONTROL,
+ .i2a_recv0 = APPLE_ASC_MBOX_I2A_RECV0,
+ .i2a_recv1 = APPLE_ASC_MBOX_I2A_RECV1,
+
+ .has_irq_controls = false,
+};
+
+static const struct apple_mbox_hw apple_mbox_m3_hw = {
+ .control_full = APPLE_M3_MBOX_CONTROL_FULL,
+ .control_empty = APPLE_M3_MBOX_CONTROL_EMPTY,
+
+ .a2i_control = APPLE_M3_MBOX_A2I_CONTROL,
+ .a2i_send0 = APPLE_M3_MBOX_A2I_SEND0,
+ .a2i_send1 = APPLE_M3_MBOX_A2I_SEND1,
+
+ .i2a_control = APPLE_M3_MBOX_I2A_CONTROL,
+ .i2a_recv0 = APPLE_M3_MBOX_I2A_RECV0,
+ .i2a_recv1 = APPLE_M3_MBOX_I2A_RECV1,
+
+ .has_irq_controls = true,
+ .irq_enable = APPLE_M3_MBOX_IRQ_ENABLE,
+ .irq_ack = APPLE_M3_MBOX_IRQ_ACK,
+ .irq_bit_recv_not_empty = APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY,
+ .irq_bit_send_empty = APPLE_M3_MBOX_IRQ_A2I_EMPTY,
+};
+
+static const struct of_device_id apple_mbox_of_match[] = {
+ { .compatible = "apple,asc-mailbox-v4", .data = &apple_mbox_asc_hw },
+ { .compatible = "apple,m3-mailbox-v2", .data = &apple_mbox_m3_hw },
+ {}
+};
+MODULE_DEVICE_TABLE(of, apple_mbox_of_match);
+
+static struct platform_driver apple_mbox_driver = {
+ .driver = {
+ .name = "apple-mailbox",
+ .of_match_table = apple_mbox_of_match,
+ },
+ .probe = apple_mbox_probe,
+};
+module_platform_driver(apple_mbox_driver);
+
+MODULE_LICENSE("Dual MIT/GPL");
+MODULE_AUTHOR("Sven Peter <[email protected]>");
+MODULE_DESCRIPTION("Apple Mailbox driver");
diff --git a/drivers/soc/apple/mailbox.h b/drivers/soc/apple/mailbox.h
new file mode 100644
index 000000000000..f73a8913da95
--- /dev/null
+++ b/drivers/soc/apple/mailbox.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/*
+ * Apple mailbox message format
+ *
+ * Copyright The Asahi Linux Contributors
+ */
+
+#ifndef _APPLE_MAILBOX_H_
+#define _APPLE_MAILBOX_H_
+
+#include <linux/device.h>
+#include <linux/types.h>
+
+/* encodes a single 96bit message sent over the single channel */
+struct apple_mbox_msg {
+ u64 msg0;
+ u32 msg1;
+};
+
+struct apple_mbox {
+ struct device *dev;
+ void __iomem *regs;
+ const struct apple_mbox_hw *hw;
+ bool active;
+
+ int irq_recv_not_empty;
+ int irq_send_empty;
+
+ spinlock_t rx_lock;
+ spinlock_t tx_lock;
+
+ struct completion tx_empty;
+
+ /** Receive callback for incoming messages */
+ void (*rx)(struct apple_mbox *mbox, struct apple_mbox_msg msg, void *cookie);
+ void *cookie;
+};
+
+struct apple_mbox *apple_mbox_get(struct device *dev, int index);
+struct apple_mbox *apple_mbox_get_byname(struct device *dev, const char *name);
+
+int apple_mbox_start(struct apple_mbox *mbox);
+void apple_mbox_stop(struct apple_mbox *mbox);
+int apple_mbox_poll(struct apple_mbox *mbox);
+int apple_mbox_send(struct apple_mbox *mbox, struct apple_mbox_msg msg,
+ bool atomic);
+
+#endif
--
2.40.0
On Tue, 28 Mar 2023 at 14:20, Hector Martin <[email protected]> wrote:
>
> It is fundamentally broken and has no users. Just remove it.
>
> Signed-off-by: Hector Martin <[email protected]>
Watched the stream
Acked-by: Eric Curtin <[email protected]>
Is mise le meas/Regards,
Eric Curtin
> ---
> drivers/soc/apple/rtkit.c | 32 --------------------------------
> include/linux/soc/apple/rtkit.h | 18 ------------------
> 2 files changed, 50 deletions(-)
>
> diff --git a/drivers/soc/apple/rtkit.c b/drivers/soc/apple/rtkit.c
> index d9f19dc99da5..7c9b9f25bbc1 100644
> --- a/drivers/soc/apple/rtkit.c
> +++ b/drivers/soc/apple/rtkit.c
> @@ -641,38 +641,6 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
> }
> EXPORT_SYMBOL_GPL(apple_rtkit_send_message);
>
> -int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message,
> - unsigned long timeout, bool atomic)
> -{
> - DECLARE_COMPLETION_ONSTACK(completion);
> - int ret;
> - long t;
> -
> - ret = apple_rtkit_send_message(rtk, ep, message, &completion, atomic);
> - if (ret < 0)
> - return ret;
> -
> - if (atomic) {
> - ret = mbox_flush(rtk->mbox_chan, timeout);
> - if (ret < 0)
> - return ret;
> -
> - if (try_wait_for_completion(&completion))
> - return 0;
> -
> - return -ETIME;
> - } else {
> - t = wait_for_completion_interruptible_timeout(
> - &completion, msecs_to_jiffies(timeout));
> - if (t < 0)
> - return t;
> - else if (t == 0)
> - return -ETIME;
> - return 0;
> - }
> -}
> -EXPORT_SYMBOL_GPL(apple_rtkit_send_message_wait);
> -
> int apple_rtkit_poll(struct apple_rtkit *rtk)
> {
> return mbox_client_peek_data(rtk->mbox_chan);
> diff --git a/include/linux/soc/apple/rtkit.h b/include/linux/soc/apple/rtkit.h
> index fc456f75c131..8c9ca857ccf6 100644
> --- a/include/linux/soc/apple/rtkit.h
> +++ b/include/linux/soc/apple/rtkit.h
> @@ -160,24 +160,6 @@ int apple_rtkit_start_ep(struct apple_rtkit *rtk, u8 endpoint);
> int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
> struct completion *completion, bool atomic);
>
> -/*
> - * Send a message to the given endpoint and wait until it has been submitted
> - * to the hardware FIFO.
> - * Will return zero on success and a negative error code on failure
> - * (e.g. -ETIME when the message couldn't be written within the given
> - * timeout)
> - *
> - * @rtk: RTKit reference
> - * @ep: target endpoint
> - * @message: message to be sent
> - * @timeout: timeout in milliseconds to allow the message transmission
> - * to be completed
> - * @atomic: if set to true this function can be called from atomic
> - * context.
> - */
> -int apple_rtkit_send_message_wait(struct apple_rtkit *rtk, u8 ep, u64 message,
> - unsigned long timeout, bool atomic);
> -
> /*
> * Process incoming messages in atomic context.
> * This only guarantees that messages arrive as far as the recv_message_early
>
> --
> 2.40.0
>
>
On Tue, 28 Mar 2023 at 14:21, Hector Martin <[email protected]> wrote:
>
> This driver is now orphaned and superseded by
> drivers/soc/apple/mailbox.c.
>
> Signed-off-by: Hector Martin <[email protected]>
Watched the stream
Acked-by: Eric Curtin <[email protected]>
Is mise le meas/Regards,
Eric Curtin
> ---
> MAINTAINERS | 2 -
> drivers/mailbox/Kconfig | 12 --
> drivers/mailbox/Makefile | 2 -
> drivers/mailbox/apple-mailbox.c | 441 ----------------------------------------
> include/linux/apple-mailbox.h | 19 --
> 5 files changed, 476 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8d5bc223f305..c115e0ad41da 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1966,7 +1966,6 @@ F: drivers/i2c/busses/i2c-pasemi-platform.c
> F: drivers/iommu/apple-dart.c
> F: drivers/iommu/io-pgtable-dart.c
> F: drivers/irqchip/irq-apple-aic.c
> -F: drivers/mailbox/apple-mailbox.c
> F: drivers/nvme/host/apple.c
> F: drivers/nvmem/apple-efuses.c
> F: drivers/pinctrl/pinctrl-apple-gpio.c
> @@ -1974,7 +1973,6 @@ F: drivers/soc/apple/*
> F: drivers/watchdog/apple_wdt.c
> F: include/dt-bindings/interrupt-controller/apple-aic.h
> F: include/dt-bindings/pinctrl/apple.h
> -F: include/linux/apple-mailbox.h
> F: include/linux/soc/apple/*
>
> ARM/APPLE MACHINE SOUND DRIVERS
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 1495965bc394..73952108cc52 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -8,18 +8,6 @@ menuconfig MAILBOX
>
> if MAILBOX
>
> -config APPLE_MAILBOX
> - tristate "Apple Mailbox driver"
> - depends on ARCH_APPLE || (ARM64 && COMPILE_TEST)
> - default ARCH_APPLE
> - help
> - Apple SoCs have various co-processors required for certain
> - peripherals to work (NVMe, display controller, etc.). This
> - driver adds support for the mailbox controller used to
> - communicate with those.
> -
> - Say Y here if you have a Apple SoC.
> -
> config ARM_MHU
> tristate "ARM MHU Mailbox"
> depends on ARM_AMBA
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index fc9376117111..18793e6caa2f 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -60,5 +60,3 @@ obj-$(CONFIG_SUN6I_MSGBOX) += sun6i-msgbox.o
> obj-$(CONFIG_SPRD_MBOX) += sprd-mailbox.o
>
> obj-$(CONFIG_QCOM_IPCC) += qcom-ipcc.o
> -
> -obj-$(CONFIG_APPLE_MAILBOX) += apple-mailbox.o
> diff --git a/drivers/mailbox/apple-mailbox.c b/drivers/mailbox/apple-mailbox.c
> deleted file mode 100644
> index 2a3e8d8ff8b5..000000000000
> --- a/drivers/mailbox/apple-mailbox.c
> +++ /dev/null
> @@ -1,441 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only OR MIT
> -/*
> - * Apple mailbox driver
> - *
> - * Copyright (C) 2021 The Asahi Linux Contributors
> - *
> - * This driver adds support for two mailbox variants (called ASC and M3 by
> - * Apple) found in Apple SoCs such as the M1. It consists of two FIFOs used to
> - * exchange 64+32 bit messages between the main CPU and a co-processor.
> - * Various coprocessors implement different IPC protocols based on these simple
> - * messages and shared memory buffers.
> - *
> - * Both the main CPU and the co-processor see the same set of registers but
> - * the first FIFO (A2I) is always used to transfer messages from the application
> - * processor (us) to the I/O processor and the second one (I2A) for the
> - * other direction.
> - */
> -
> -#include <linux/apple-mailbox.h>
> -#include <linux/delay.h>
> -#include <linux/device.h>
> -#include <linux/gfp.h>
> -#include <linux/interrupt.h>
> -#include <linux/io.h>
> -#include <linux/mailbox_controller.h>
> -#include <linux/module.h>
> -#include <linux/of.h>
> -#include <linux/platform_device.h>
> -#include <linux/spinlock.h>
> -#include <linux/types.h>
> -
> -#define APPLE_ASC_MBOX_CONTROL_FULL BIT(16)
> -#define APPLE_ASC_MBOX_CONTROL_EMPTY BIT(17)
> -
> -#define APPLE_ASC_MBOX_A2I_CONTROL 0x110
> -#define APPLE_ASC_MBOX_A2I_SEND0 0x800
> -#define APPLE_ASC_MBOX_A2I_SEND1 0x808
> -#define APPLE_ASC_MBOX_A2I_RECV0 0x810
> -#define APPLE_ASC_MBOX_A2I_RECV1 0x818
> -
> -#define APPLE_ASC_MBOX_I2A_CONTROL 0x114
> -#define APPLE_ASC_MBOX_I2A_SEND0 0x820
> -#define APPLE_ASC_MBOX_I2A_SEND1 0x828
> -#define APPLE_ASC_MBOX_I2A_RECV0 0x830
> -#define APPLE_ASC_MBOX_I2A_RECV1 0x838
> -
> -#define APPLE_M3_MBOX_CONTROL_FULL BIT(16)
> -#define APPLE_M3_MBOX_CONTROL_EMPTY BIT(17)
> -
> -#define APPLE_M3_MBOX_A2I_CONTROL 0x50
> -#define APPLE_M3_MBOX_A2I_SEND0 0x60
> -#define APPLE_M3_MBOX_A2I_SEND1 0x68
> -#define APPLE_M3_MBOX_A2I_RECV0 0x70
> -#define APPLE_M3_MBOX_A2I_RECV1 0x78
> -
> -#define APPLE_M3_MBOX_I2A_CONTROL 0x80
> -#define APPLE_M3_MBOX_I2A_SEND0 0x90
> -#define APPLE_M3_MBOX_I2A_SEND1 0x98
> -#define APPLE_M3_MBOX_I2A_RECV0 0xa0
> -#define APPLE_M3_MBOX_I2A_RECV1 0xa8
> -
> -#define APPLE_M3_MBOX_IRQ_ENABLE 0x48
> -#define APPLE_M3_MBOX_IRQ_ACK 0x4c
> -#define APPLE_M3_MBOX_IRQ_A2I_EMPTY BIT(0)
> -#define APPLE_M3_MBOX_IRQ_A2I_NOT_EMPTY BIT(1)
> -#define APPLE_M3_MBOX_IRQ_I2A_EMPTY BIT(2)
> -#define APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY BIT(3)
> -
> -#define APPLE_MBOX_MSG1_OUTCNT GENMASK(56, 52)
> -#define APPLE_MBOX_MSG1_INCNT GENMASK(51, 48)
> -#define APPLE_MBOX_MSG1_OUTPTR GENMASK(47, 44)
> -#define APPLE_MBOX_MSG1_INPTR GENMASK(43, 40)
> -#define APPLE_MBOX_MSG1_MSG GENMASK(31, 0)
> -
> -struct apple_mbox_hw {
> - unsigned int control_full;
> - unsigned int control_empty;
> -
> - unsigned int a2i_control;
> - unsigned int a2i_send0;
> - unsigned int a2i_send1;
> -
> - unsigned int i2a_control;
> - unsigned int i2a_recv0;
> - unsigned int i2a_recv1;
> -
> - bool has_irq_controls;
> - unsigned int irq_enable;
> - unsigned int irq_ack;
> - unsigned int irq_bit_recv_not_empty;
> - unsigned int irq_bit_send_empty;
> -};
> -
> -struct apple_mbox {
> - void __iomem *regs;
> - const struct apple_mbox_hw *hw;
> -
> - int irq_recv_not_empty;
> - int irq_send_empty;
> -
> - struct mbox_chan chan;
> -
> - struct device *dev;
> - struct mbox_controller controller;
> - spinlock_t rx_lock;
> -};
> -
> -static const struct of_device_id apple_mbox_of_match[];
> -
> -static bool apple_mbox_hw_can_send(struct apple_mbox *apple_mbox)
> -{
> - u32 mbox_ctrl =
> - readl_relaxed(apple_mbox->regs + apple_mbox->hw->a2i_control);
> -
> - return !(mbox_ctrl & apple_mbox->hw->control_full);
> -}
> -
> -static bool apple_mbox_hw_send_empty(struct apple_mbox *apple_mbox)
> -{
> - u32 mbox_ctrl =
> - readl_relaxed(apple_mbox->regs + apple_mbox->hw->a2i_control);
> -
> - return mbox_ctrl & apple_mbox->hw->control_empty;
> -}
> -
> -static int apple_mbox_hw_send(struct apple_mbox *apple_mbox,
> - struct apple_mbox_msg *msg)
> -{
> - if (!apple_mbox_hw_can_send(apple_mbox))
> - return -EBUSY;
> -
> - dev_dbg(apple_mbox->dev, "> TX %016llx %08x\n", msg->msg0, msg->msg1);
> -
> - writeq_relaxed(msg->msg0, apple_mbox->regs + apple_mbox->hw->a2i_send0);
> - writeq_relaxed(FIELD_PREP(APPLE_MBOX_MSG1_MSG, msg->msg1),
> - apple_mbox->regs + apple_mbox->hw->a2i_send1);
> -
> - return 0;
> -}
> -
> -static bool apple_mbox_hw_can_recv(struct apple_mbox *apple_mbox)
> -{
> - u32 mbox_ctrl =
> - readl_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_control);
> -
> - return !(mbox_ctrl & apple_mbox->hw->control_empty);
> -}
> -
> -static int apple_mbox_hw_recv(struct apple_mbox *apple_mbox,
> - struct apple_mbox_msg *msg)
> -{
> - if (!apple_mbox_hw_can_recv(apple_mbox))
> - return -ENOMSG;
> -
> - msg->msg0 = readq_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_recv0);
> - msg->msg1 = FIELD_GET(
> - APPLE_MBOX_MSG1_MSG,
> - readq_relaxed(apple_mbox->regs + apple_mbox->hw->i2a_recv1));
> -
> - dev_dbg(apple_mbox->dev, "< RX %016llx %08x\n", msg->msg0, msg->msg1);
> -
> - return 0;
> -}
> -
> -static int apple_mbox_chan_send_data(struct mbox_chan *chan, void *data)
> -{
> - struct apple_mbox *apple_mbox = chan->con_priv;
> - struct apple_mbox_msg *msg = data;
> - int ret;
> -
> - ret = apple_mbox_hw_send(apple_mbox, msg);
> - if (ret)
> - return ret;
> -
> - /*
> - * The interrupt is level triggered and will keep firing as long as the
> - * FIFO is empty. It will also keep firing if the FIFO was empty
> - * at any point in the past until it has been acknowledged at the
> - * mailbox level. By acknowledging it here we can ensure that we will
> - * only get the interrupt once the FIFO has been cleared again.
> - * If the FIFO is already empty before the ack it will fire again
> - * immediately after the ack.
> - */
> - if (apple_mbox->hw->has_irq_controls) {
> - writel_relaxed(apple_mbox->hw->irq_bit_send_empty,
> - apple_mbox->regs + apple_mbox->hw->irq_ack);
> - }
> - enable_irq(apple_mbox->irq_send_empty);
> -
> - return 0;
> -}
> -
> -static irqreturn_t apple_mbox_send_empty_irq(int irq, void *data)
> -{
> - struct apple_mbox *apple_mbox = data;
> -
> - /*
> - * We don't need to acknowledge the interrupt at the mailbox level
> - * here even if supported by the hardware. It will keep firing but that
> - * doesn't matter since it's disabled at the main interrupt controller.
> - * apple_mbox_chan_send_data will acknowledge it before enabling
> - * it at the main controller again.
> - */
> - disable_irq_nosync(apple_mbox->irq_send_empty);
> - mbox_chan_txdone(&apple_mbox->chan, 0);
> - return IRQ_HANDLED;
> -}
> -
> -static int apple_mbox_poll(struct apple_mbox *apple_mbox)
> -{
> - struct apple_mbox_msg msg;
> - int ret = 0;
> -
> - while (apple_mbox_hw_recv(apple_mbox, &msg) == 0) {
> - mbox_chan_received_data(&apple_mbox->chan, (void *)&msg);
> - ret++;
> - }
> -
> - /*
> - * The interrupt will keep firing even if there are no more messages
> - * unless we also acknowledge it at the mailbox level here.
> - * There's no race if a message comes in between the check in the while
> - * loop above and the ack below: If a new messages arrives inbetween
> - * those two the interrupt will just fire again immediately after the
> - * ack since it's level triggered.
> - */
> - if (apple_mbox->hw->has_irq_controls) {
> - writel_relaxed(apple_mbox->hw->irq_bit_recv_not_empty,
> - apple_mbox->regs + apple_mbox->hw->irq_ack);
> - }
> -
> - return ret;
> -}
> -
> -static irqreturn_t apple_mbox_recv_irq(int irq, void *data)
> -{
> - struct apple_mbox *apple_mbox = data;
> -
> - spin_lock(&apple_mbox->rx_lock);
> - apple_mbox_poll(apple_mbox);
> - spin_unlock(&apple_mbox->rx_lock);
> -
> - return IRQ_HANDLED;
> -}
> -
> -static bool apple_mbox_chan_peek_data(struct mbox_chan *chan)
> -{
> - struct apple_mbox *apple_mbox = chan->con_priv;
> - unsigned long flags;
> - int ret;
> -
> - spin_lock_irqsave(&apple_mbox->rx_lock, flags);
> - ret = apple_mbox_poll(apple_mbox);
> - spin_unlock_irqrestore(&apple_mbox->rx_lock, flags);
> -
> - return ret > 0;
> -}
> -
> -static int apple_mbox_chan_flush(struct mbox_chan *chan, unsigned long timeout)
> -{
> - struct apple_mbox *apple_mbox = chan->con_priv;
> - unsigned long deadline = jiffies + msecs_to_jiffies(timeout);
> -
> - while (time_before(jiffies, deadline)) {
> - if (apple_mbox_hw_send_empty(apple_mbox)) {
> - mbox_chan_txdone(&apple_mbox->chan, 0);
> - return 0;
> - }
> -
> - udelay(1);
> - }
> -
> - return -ETIME;
> -}
> -
> -static int apple_mbox_chan_startup(struct mbox_chan *chan)
> -{
> - struct apple_mbox *apple_mbox = chan->con_priv;
> -
> - /*
> - * Only some variants of this mailbox HW provide interrupt control
> - * at the mailbox level. We therefore need to handle enabling/disabling
> - * interrupts at the main interrupt controller anyway for hardware that
> - * doesn't. Just always keep the interrupts we care about enabled at
> - * the mailbox level so that both hardware revisions behave almost
> - * the same.
> - */
> - if (apple_mbox->hw->has_irq_controls) {
> - writel_relaxed(apple_mbox->hw->irq_bit_recv_not_empty |
> - apple_mbox->hw->irq_bit_send_empty,
> - apple_mbox->regs + apple_mbox->hw->irq_enable);
> - }
> -
> - enable_irq(apple_mbox->irq_recv_not_empty);
> - return 0;
> -}
> -
> -static void apple_mbox_chan_shutdown(struct mbox_chan *chan)
> -{
> - struct apple_mbox *apple_mbox = chan->con_priv;
> -
> - disable_irq(apple_mbox->irq_recv_not_empty);
> -}
> -
> -static const struct mbox_chan_ops apple_mbox_ops = {
> - .send_data = apple_mbox_chan_send_data,
> - .peek_data = apple_mbox_chan_peek_data,
> - .flush = apple_mbox_chan_flush,
> - .startup = apple_mbox_chan_startup,
> - .shutdown = apple_mbox_chan_shutdown,
> -};
> -
> -static struct mbox_chan *apple_mbox_of_xlate(struct mbox_controller *mbox,
> - const struct of_phandle_args *args)
> -{
> - if (args->args_count != 0)
> - return ERR_PTR(-EINVAL);
> -
> - return &mbox->chans[0];
> -}
> -
> -static int apple_mbox_probe(struct platform_device *pdev)
> -{
> - int ret;
> - const struct of_device_id *match;
> - char *irqname;
> - struct apple_mbox *mbox;
> - struct device *dev = &pdev->dev;
> -
> - match = of_match_node(apple_mbox_of_match, pdev->dev.of_node);
> - if (!match)
> - return -EINVAL;
> - if (!match->data)
> - return -EINVAL;
> -
> - mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> - if (!mbox)
> - return -ENOMEM;
> - platform_set_drvdata(pdev, mbox);
> -
> - mbox->dev = dev;
> - mbox->regs = devm_platform_ioremap_resource(pdev, 0);
> - if (IS_ERR(mbox->regs))
> - return PTR_ERR(mbox->regs);
> -
> - mbox->hw = match->data;
> - mbox->irq_recv_not_empty =
> - platform_get_irq_byname(pdev, "recv-not-empty");
> - if (mbox->irq_recv_not_empty < 0)
> - return -ENODEV;
> -
> - mbox->irq_send_empty = platform_get_irq_byname(pdev, "send-empty");
> - if (mbox->irq_send_empty < 0)
> - return -ENODEV;
> -
> - mbox->controller.dev = mbox->dev;
> - mbox->controller.num_chans = 1;
> - mbox->controller.chans = &mbox->chan;
> - mbox->controller.ops = &apple_mbox_ops;
> - mbox->controller.txdone_irq = true;
> - mbox->controller.of_xlate = apple_mbox_of_xlate;
> - mbox->chan.con_priv = mbox;
> - spin_lock_init(&mbox->rx_lock);
> -
> - irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-recv", dev_name(dev));
> - if (!irqname)
> - return -ENOMEM;
> -
> - ret = devm_request_threaded_irq(dev, mbox->irq_recv_not_empty, NULL,
> - apple_mbox_recv_irq,
> - IRQF_NO_AUTOEN | IRQF_ONESHOT, irqname,
> - mbox);
> - if (ret)
> - return ret;
> -
> - irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-send", dev_name(dev));
> - if (!irqname)
> - return -ENOMEM;
> -
> - ret = devm_request_irq(dev, mbox->irq_send_empty,
> - apple_mbox_send_empty_irq, IRQF_NO_AUTOEN,
> - irqname, mbox);
> - if (ret)
> - return ret;
> -
> - return devm_mbox_controller_register(dev, &mbox->controller);
> -}
> -
> -static const struct apple_mbox_hw apple_mbox_asc_hw = {
> - .control_full = APPLE_ASC_MBOX_CONTROL_FULL,
> - .control_empty = APPLE_ASC_MBOX_CONTROL_EMPTY,
> -
> - .a2i_control = APPLE_ASC_MBOX_A2I_CONTROL,
> - .a2i_send0 = APPLE_ASC_MBOX_A2I_SEND0,
> - .a2i_send1 = APPLE_ASC_MBOX_A2I_SEND1,
> -
> - .i2a_control = APPLE_ASC_MBOX_I2A_CONTROL,
> - .i2a_recv0 = APPLE_ASC_MBOX_I2A_RECV0,
> - .i2a_recv1 = APPLE_ASC_MBOX_I2A_RECV1,
> -
> - .has_irq_controls = false,
> -};
> -
> -static const struct apple_mbox_hw apple_mbox_m3_hw = {
> - .control_full = APPLE_M3_MBOX_CONTROL_FULL,
> - .control_empty = APPLE_M3_MBOX_CONTROL_EMPTY,
> -
> - .a2i_control = APPLE_M3_MBOX_A2I_CONTROL,
> - .a2i_send0 = APPLE_M3_MBOX_A2I_SEND0,
> - .a2i_send1 = APPLE_M3_MBOX_A2I_SEND1,
> -
> - .i2a_control = APPLE_M3_MBOX_I2A_CONTROL,
> - .i2a_recv0 = APPLE_M3_MBOX_I2A_RECV0,
> - .i2a_recv1 = APPLE_M3_MBOX_I2A_RECV1,
> -
> - .has_irq_controls = true,
> - .irq_enable = APPLE_M3_MBOX_IRQ_ENABLE,
> - .irq_ack = APPLE_M3_MBOX_IRQ_ACK,
> - .irq_bit_recv_not_empty = APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY,
> - .irq_bit_send_empty = APPLE_M3_MBOX_IRQ_A2I_EMPTY,
> -};
> -
> -static const struct of_device_id apple_mbox_of_match[] = {
> - { .compatible = "apple,asc-mailbox-v4", .data = &apple_mbox_asc_hw },
> - { .compatible = "apple,m3-mailbox-v2", .data = &apple_mbox_m3_hw },
> - {}
> -};
> -MODULE_DEVICE_TABLE(of, apple_mbox_of_match);
> -
> -static struct platform_driver apple_mbox_driver = {
> - .driver = {
> - .name = "apple-mailbox",
> - .of_match_table = apple_mbox_of_match,
> - },
> - .probe = apple_mbox_probe,
> -};
> -module_platform_driver(apple_mbox_driver);
> -
> -MODULE_LICENSE("Dual MIT/GPL");
> -MODULE_AUTHOR("Sven Peter <[email protected]>");
> -MODULE_DESCRIPTION("Apple Mailbox driver");
> diff --git a/include/linux/apple-mailbox.h b/include/linux/apple-mailbox.h
> deleted file mode 100644
> index 720fbb70294a..000000000000
> --- a/include/linux/apple-mailbox.h
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> -/*
> - * Apple mailbox message format
> - *
> - * Copyright (C) 2021 The Asahi Linux Contributors
> - */
> -
> -#ifndef _LINUX_APPLE_MAILBOX_H_
> -#define _LINUX_APPLE_MAILBOX_H_
> -
> -#include <linux/types.h>
> -
> -/* encodes a single 96bit message sent over the single channel */
> -struct apple_mbox_msg {
> - u64 msg0;
> - u32 msg1;
> -};
> -
> -#endif
>
> --
> 2.40.0
>
>
On Tue, 28 Mar 2023 at 14:21, Hector Martin <[email protected]> wrote:
>
> Now that we have a mailbox driver in drivers/soc/apple, port the RTKit
> code to it. This mostly just entails replacing calls through the mailbox
> subsystem with direct calls into the driver.
>
> Signed-off-by: Hector Martin <[email protected]>
Watched the stream
Acked-by: Eric Curtin <[email protected]>
Is mise le meas/Regards,
Eric Curtin
> ---
> drivers/soc/apple/Kconfig | 2 +-
> drivers/soc/apple/rtkit-internal.h | 8 +--
> drivers/soc/apple/rtkit.c | 101 ++++++++++---------------------------
> 3 files changed, 31 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
> index caa2cf09ff7a..d0e29bbd8c6f 100644
> --- a/drivers/soc/apple/Kconfig
> +++ b/drivers/soc/apple/Kconfig
> @@ -33,7 +33,7 @@ config APPLE_MBOX
>
> config APPLE_RTKIT
> tristate "Apple RTKit co-processor IPC protocol"
> - depends on MAILBOX
> + depends on APPLE_MBOX
> depends on ARCH_APPLE || COMPILE_TEST
> default ARCH_APPLE
> help
> diff --git a/drivers/soc/apple/rtkit-internal.h b/drivers/soc/apple/rtkit-internal.h
> index 24bd619ec5e4..27c9fa745fd5 100644
> --- a/drivers/soc/apple/rtkit-internal.h
> +++ b/drivers/soc/apple/rtkit-internal.h
> @@ -7,18 +7,17 @@
> #ifndef _APPLE_RTKIT_INTERAL_H
> #define _APPLE_RTKIT_INTERAL_H
>
> -#include <linux/apple-mailbox.h>
> #include <linux/bitfield.h>
> #include <linux/bitmap.h>
> #include <linux/completion.h>
> #include <linux/dma-mapping.h>
> #include <linux/io.h>
> #include <linux/kernel.h>
> -#include <linux/mailbox_client.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/soc/apple/rtkit.h>
> #include <linux/workqueue.h>
> +#include "mailbox.h"
>
> #define APPLE_RTKIT_APP_ENDPOINT_START 0x20
> #define APPLE_RTKIT_MAX_ENDPOINTS 0x100
> @@ -28,10 +27,7 @@ struct apple_rtkit {
> const struct apple_rtkit_ops *ops;
> struct device *dev;
>
> - const char *mbox_name;
> - int mbox_idx;
> - struct mbox_client mbox_cl;
> - struct mbox_chan *mbox_chan;
> + struct apple_mbox *mbox;
>
> struct completion epmap_completion;
> struct completion iop_pwr_ack_completion;
> diff --git a/drivers/soc/apple/rtkit.c b/drivers/soc/apple/rtkit.c
> index 7c9b9f25bbc1..e6d940292c9f 100644
> --- a/drivers/soc/apple/rtkit.c
> +++ b/drivers/soc/apple/rtkit.c
> @@ -72,11 +72,6 @@ enum {
> #define APPLE_RTKIT_MIN_SUPPORTED_VERSION 11
> #define APPLE_RTKIT_MAX_SUPPORTED_VERSION 12
>
> -struct apple_rtkit_msg {
> - struct completion *completion;
> - struct apple_mbox_msg mbox_msg;
> -};
> -
> struct apple_rtkit_rx_work {
> struct apple_rtkit *rtk;
> u8 ep;
> @@ -550,12 +545,12 @@ static void apple_rtkit_rx_work(struct work_struct *work)
> kfree(rtk_work);
> }
>
> -static void apple_rtkit_rx(struct mbox_client *cl, void *mssg)
> +static void apple_rtkit_rx(struct apple_mbox *mbox, struct apple_mbox_msg msg,
> + void *cookie)
> {
> - struct apple_rtkit *rtk = container_of(cl, struct apple_rtkit, mbox_cl);
> - struct apple_mbox_msg *msg = mssg;
> + struct apple_rtkit *rtk = cookie;
> struct apple_rtkit_rx_work *work;
> - u8 ep = msg->msg1;
> + u8 ep = msg.msg1;
>
> /*
> * The message was read from a MMIO FIFO and we have to make
> @@ -571,7 +566,7 @@ static void apple_rtkit_rx(struct mbox_client *cl, void *mssg)
>
> if (ep >= APPLE_RTKIT_APP_ENDPOINT_START &&
> rtk->ops->recv_message_early &&
> - rtk->ops->recv_message_early(rtk->cookie, ep, msg->msg0))
> + rtk->ops->recv_message_early(rtk->cookie, ep, msg.msg0))
> return;
>
> work = kzalloc(sizeof(*work), GFP_ATOMIC);
> @@ -580,30 +575,18 @@ static void apple_rtkit_rx(struct mbox_client *cl, void *mssg)
>
> work->rtk = rtk;
> work->ep = ep;
> - work->msg = msg->msg0;
> + work->msg = msg.msg0;
> INIT_WORK(&work->work, apple_rtkit_rx_work);
> queue_work(rtk->wq, &work->work);
> }
>
> -static void apple_rtkit_tx_done(struct mbox_client *cl, void *mssg, int r)
> -{
> - struct apple_rtkit_msg *msg =
> - container_of(mssg, struct apple_rtkit_msg, mbox_msg);
> -
> - if (r == -ETIME)
> - return;
> -
> - if (msg->completion)
> - complete(msg->completion);
> - kfree(msg);
> -}
> -
> int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
> struct completion *completion, bool atomic)
> {
> - struct apple_rtkit_msg *msg;
> - int ret;
> - gfp_t flags;
> + struct apple_mbox_msg msg = {
> + .msg0 = message,
> + .msg1 = ep,
> + };
>
> if (rtk->crashed)
> return -EINVAL;
> @@ -611,19 +594,6 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
> !apple_rtkit_is_running(rtk))
> return -EINVAL;
>
> - if (atomic)
> - flags = GFP_ATOMIC;
> - else
> - flags = GFP_KERNEL;
> -
> - msg = kzalloc(sizeof(*msg), flags);
> - if (!msg)
> - return -ENOMEM;
> -
> - msg->mbox_msg.msg0 = message;
> - msg->mbox_msg.msg1 = ep;
> - msg->completion = completion;
> -
> /*
> * The message will be sent with a MMIO write. We need the barrier
> * here to ensure any previous writes to buffers are visible to the
> @@ -631,19 +601,13 @@ int apple_rtkit_send_message(struct apple_rtkit *rtk, u8 ep, u64 message,
> */
> dma_wmb();
>
> - ret = mbox_send_message(rtk->mbox_chan, &msg->mbox_msg);
> - if (ret < 0) {
> - kfree(msg);
> - return ret;
> - }
> -
> - return 0;
> + return apple_mbox_send(rtk->mbox, msg, atomic);
> }
> EXPORT_SYMBOL_GPL(apple_rtkit_send_message);
>
> int apple_rtkit_poll(struct apple_rtkit *rtk)
> {
> - return mbox_client_peek_data(rtk->mbox_chan);
> + return apple_mbox_poll(rtk->mbox);
> }
> EXPORT_SYMBOL_GPL(apple_rtkit_poll);
>
> @@ -665,20 +629,6 @@ int apple_rtkit_start_ep(struct apple_rtkit *rtk, u8 endpoint)
> }
> EXPORT_SYMBOL_GPL(apple_rtkit_start_ep);
>
> -static int apple_rtkit_request_mbox_chan(struct apple_rtkit *rtk)
> -{
> - if (rtk->mbox_name)
> - rtk->mbox_chan = mbox_request_channel_byname(&rtk->mbox_cl,
> - rtk->mbox_name);
> - else
> - rtk->mbox_chan =
> - mbox_request_channel(&rtk->mbox_cl, rtk->mbox_idx);
> -
> - if (IS_ERR(rtk->mbox_chan))
> - return PTR_ERR(rtk->mbox_chan);
> - return 0;
> -}
> -
> struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie,
> const char *mbox_name, int mbox_idx,
> const struct apple_rtkit_ops *ops)
> @@ -704,13 +654,18 @@ struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie,
> bitmap_zero(rtk->endpoints, APPLE_RTKIT_MAX_ENDPOINTS);
> set_bit(APPLE_RTKIT_EP_MGMT, rtk->endpoints);
>
> - rtk->mbox_name = mbox_name;
> - rtk->mbox_idx = mbox_idx;
> - rtk->mbox_cl.dev = dev;
> - rtk->mbox_cl.tx_block = false;
> - rtk->mbox_cl.knows_txdone = false;
> - rtk->mbox_cl.rx_callback = &apple_rtkit_rx;
> - rtk->mbox_cl.tx_done = &apple_rtkit_tx_done;
> + if (mbox_name)
> + rtk->mbox = apple_mbox_get_byname(dev, mbox_name);
> + else
> + rtk->mbox = apple_mbox_get(dev, mbox_idx);
> +
> + if (IS_ERR(rtk->mbox)) {
> + ret = PTR_ERR(rtk->mbox);
> + goto free_rtk;
> + }
> +
> + rtk->mbox->rx = apple_rtkit_rx;
> + rtk->mbox->cookie = rtk;
>
> rtk->wq = alloc_ordered_workqueue("rtkit-%s", WQ_MEM_RECLAIM,
> dev_name(rtk->dev));
> @@ -719,7 +674,7 @@ struct apple_rtkit *apple_rtkit_init(struct device *dev, void *cookie,
> goto free_rtk;
> }
>
> - ret = apple_rtkit_request_mbox_chan(rtk);
> + ret = apple_mbox_start(rtk->mbox);
> if (ret)
> goto destroy_wq;
>
> @@ -750,7 +705,7 @@ static int apple_rtkit_wait_for_completion(struct completion *c)
> int apple_rtkit_reinit(struct apple_rtkit *rtk)
> {
> /* make sure we don't handle any messages while reinitializing */
> - mbox_free_channel(rtk->mbox_chan);
> + apple_mbox_stop(rtk->mbox);
> flush_workqueue(rtk->wq);
>
> apple_rtkit_free_buffer(rtk, &rtk->ioreport_buffer);
> @@ -774,7 +729,7 @@ int apple_rtkit_reinit(struct apple_rtkit *rtk)
> rtk->iop_power_state = APPLE_RTKIT_PWR_STATE_OFF;
> rtk->ap_power_state = APPLE_RTKIT_PWR_STATE_OFF;
>
> - return apple_rtkit_request_mbox_chan(rtk);
> + return apple_mbox_start(rtk->mbox);
> }
> EXPORT_SYMBOL_GPL(apple_rtkit_reinit);
>
> @@ -930,7 +885,7 @@ EXPORT_SYMBOL_GPL(apple_rtkit_wake);
>
> void apple_rtkit_free(struct apple_rtkit *rtk)
> {
> - mbox_free_channel(rtk->mbox_chan);
> + apple_mbox_stop(rtk->mbox);
> destroy_workqueue(rtk->wq);
>
> apple_rtkit_free_buffer(rtk, &rtk->ioreport_buffer);
>
> --
> 2.40.0
>
>
On Tue, 28 Mar 2023 at 14:21, Hector Martin <[email protected]> wrote:
>
> With the original owner of APPLE_MAILBOX removed, let's rename the new
> APPLE_MBOX to the old name. This avoids .config churn for downstream
> users, and leaves us with an identical config symbol and module name as
> before.
>
> Signed-off-by: Hector Martin <[email protected]>
Watched the stream
Acked-by: Eric Curtin <[email protected]>
Is mise le meas/Regards,
Eric Curtin
> ---
> drivers/soc/apple/Kconfig | 5 ++---
> drivers/soc/apple/Makefile | 2 +-
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
> index d0e29bbd8c6f..c5203c388bf4 100644
> --- a/drivers/soc/apple/Kconfig
> +++ b/drivers/soc/apple/Kconfig
> @@ -17,11 +17,10 @@ config APPLE_PMGR_PWRSTATE
> controls for SoC devices. This driver manages them through the
> generic power domain framework, and also provides reset support.
>
> -config APPLE_MBOX
> +config APPLE_MAILBOX
> tristate "Apple SoC mailboxes"
> depends on PM
> depends on ARCH_APPLE || (64BIT && COMPILE_TEST)
> - depends on !APPLE_MAILBOX
> default ARCH_APPLE
> help
> Apple SoCs have various co-processors required for certain
> @@ -33,7 +32,7 @@ config APPLE_MBOX
>
> config APPLE_RTKIT
> tristate "Apple RTKit co-processor IPC protocol"
> - depends on APPLE_MBOX
> + depends on APPLE_MAILBOX
> depends on ARCH_APPLE || COMPILE_TEST
> default ARCH_APPLE
> help
> diff --git a/drivers/soc/apple/Makefile b/drivers/soc/apple/Makefile
> index e52edf6a73da..20feee6f3943 100644
> --- a/drivers/soc/apple/Makefile
> +++ b/drivers/soc/apple/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_APPLE_PMGR_PWRSTATE) += apple-pmgr-pwrstate.o
>
> -obj-$(CONFIG_APPLE_MBOX) += apple-mailbox.o
> +obj-$(CONFIG_APPLE_MAILBOX) += apple-mailbox.o
> apple-mailbox-y = mailbox.o
>
> obj-$(CONFIG_APPLE_RTKIT) += apple-rtkit.o
>
> --
> 2.40.0
>
>
On Tue, 28 Mar 2023 at 14:20, Hector Martin <[email protected]> wrote:
>
> This new driver is based on the existing apple-mailbox driver, but
> replaces the usage of the mailbox subsystem with directly exported
> symbols.
>
> As part of this refactor, this adds support for using the hardware FIFOs
> (not supported in mailbox) and implicitly fixes a bunch of bugs caused
> by bad interactions with the mailbox subsystem. It also adds runtime-PM
> support.
>
> The new config symbol is APPLE_MBOX, while the module name remains
> identical ("apple-mailbox"). The configs are mutually exclusive in
> Kconfig, to avoid conflicts.
>
> Signed-off-by: Hector Martin <[email protected]>
Watched the stream
Acked-by: Eric Curtin <[email protected]>
Is mise le meas/Regards,
Eric Curtin
> ---
> drivers/soc/apple/Kconfig | 14 ++
> drivers/soc/apple/Makefile | 3 +
> drivers/soc/apple/mailbox.c | 434 ++++++++++++++++++++++++++++++++++++++++++++
> drivers/soc/apple/mailbox.h | 48 +++++
> 4 files changed, 499 insertions(+)
>
> diff --git a/drivers/soc/apple/Kconfig b/drivers/soc/apple/Kconfig
> index a1596fefacff..caa2cf09ff7a 100644
> --- a/drivers/soc/apple/Kconfig
> +++ b/drivers/soc/apple/Kconfig
> @@ -17,6 +17,20 @@ config APPLE_PMGR_PWRSTATE
> controls for SoC devices. This driver manages them through the
> generic power domain framework, and also provides reset support.
>
> +config APPLE_MBOX
> + tristate "Apple SoC mailboxes"
> + depends on PM
> + depends on ARCH_APPLE || (64BIT && COMPILE_TEST)
> + depends on !APPLE_MAILBOX
> + default ARCH_APPLE
> + help
> + Apple SoCs have various co-processors required for certain
> + peripherals to work (NVMe, display controller, etc.). This
> + driver adds support for the mailbox controller used to
> + communicate with those.
> +
> + Say Y here if you have an Apple SoC.
> +
> config APPLE_RTKIT
> tristate "Apple RTKit co-processor IPC protocol"
> depends on MAILBOX
> diff --git a/drivers/soc/apple/Makefile b/drivers/soc/apple/Makefile
> index e293770cf66d..e52edf6a73da 100644
> --- a/drivers/soc/apple/Makefile
> +++ b/drivers/soc/apple/Makefile
> @@ -1,6 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_APPLE_PMGR_PWRSTATE) += apple-pmgr-pwrstate.o
>
> +obj-$(CONFIG_APPLE_MBOX) += apple-mailbox.o
> +apple-mailbox-y = mailbox.o
> +
> obj-$(CONFIG_APPLE_RTKIT) += apple-rtkit.o
> apple-rtkit-y = rtkit.o rtkit-crashlog.o
>
> diff --git a/drivers/soc/apple/mailbox.c b/drivers/soc/apple/mailbox.c
> new file mode 100644
> index 000000000000..7bdebafa6e83
> --- /dev/null
> +++ b/drivers/soc/apple/mailbox.c
> @@ -0,0 +1,434 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple mailbox driver
> + *
> + * Copyright The Asahi Linux Contributors
> + *
> + * This driver adds support for two mailbox variants (called ASC and M3 by
> + * Apple) found in Apple SoCs such as the M1. It consists of two FIFOs used to
> + * exchange 64+32 bit messages between the main CPU and a co-processor.
> + * Various coprocessors implement different IPC protocols based on these simple
> + * messages and shared memory buffers.
> + *
> + * Both the main CPU and the co-processor see the same set of registers but
> + * the first FIFO (A2I) is always used to transfer messages from the application
> + * processor (us) to the I/O processor and the second one (I2A) for the
> + * other direction.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>
> +#include "mailbox.h"
> +
> +#define APPLE_ASC_MBOX_CONTROL_FULL BIT(16)
> +#define APPLE_ASC_MBOX_CONTROL_EMPTY BIT(17)
> +
> +#define APPLE_ASC_MBOX_A2I_CONTROL 0x110
> +#define APPLE_ASC_MBOX_A2I_SEND0 0x800
> +#define APPLE_ASC_MBOX_A2I_SEND1 0x808
> +#define APPLE_ASC_MBOX_A2I_RECV0 0x810
> +#define APPLE_ASC_MBOX_A2I_RECV1 0x818
> +
> +#define APPLE_ASC_MBOX_I2A_CONTROL 0x114
> +#define APPLE_ASC_MBOX_I2A_SEND0 0x820
> +#define APPLE_ASC_MBOX_I2A_SEND1 0x828
> +#define APPLE_ASC_MBOX_I2A_RECV0 0x830
> +#define APPLE_ASC_MBOX_I2A_RECV1 0x838
> +
> +#define APPLE_M3_MBOX_CONTROL_FULL BIT(16)
> +#define APPLE_M3_MBOX_CONTROL_EMPTY BIT(17)
> +
> +#define APPLE_M3_MBOX_A2I_CONTROL 0x50
> +#define APPLE_M3_MBOX_A2I_SEND0 0x60
> +#define APPLE_M3_MBOX_A2I_SEND1 0x68
> +#define APPLE_M3_MBOX_A2I_RECV0 0x70
> +#define APPLE_M3_MBOX_A2I_RECV1 0x78
> +
> +#define APPLE_M3_MBOX_I2A_CONTROL 0x80
> +#define APPLE_M3_MBOX_I2A_SEND0 0x90
> +#define APPLE_M3_MBOX_I2A_SEND1 0x98
> +#define APPLE_M3_MBOX_I2A_RECV0 0xa0
> +#define APPLE_M3_MBOX_I2A_RECV1 0xa8
> +
> +#define APPLE_M3_MBOX_IRQ_ENABLE 0x48
> +#define APPLE_M3_MBOX_IRQ_ACK 0x4c
> +#define APPLE_M3_MBOX_IRQ_A2I_EMPTY BIT(0)
> +#define APPLE_M3_MBOX_IRQ_A2I_NOT_EMPTY BIT(1)
> +#define APPLE_M3_MBOX_IRQ_I2A_EMPTY BIT(2)
> +#define APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY BIT(3)
> +
> +#define APPLE_MBOX_MSG1_OUTCNT GENMASK(56, 52)
> +#define APPLE_MBOX_MSG1_INCNT GENMASK(51, 48)
> +#define APPLE_MBOX_MSG1_OUTPTR GENMASK(47, 44)
> +#define APPLE_MBOX_MSG1_INPTR GENMASK(43, 40)
> +#define APPLE_MBOX_MSG1_MSG GENMASK(31, 0)
> +
> +#define APPLE_MBOX_TX_TIMEOUT 500
> +
> +struct apple_mbox_hw {
> + unsigned int control_full;
> + unsigned int control_empty;
> +
> + unsigned int a2i_control;
> + unsigned int a2i_send0;
> + unsigned int a2i_send1;
> +
> + unsigned int i2a_control;
> + unsigned int i2a_recv0;
> + unsigned int i2a_recv1;
> +
> + bool has_irq_controls;
> + unsigned int irq_enable;
> + unsigned int irq_ack;
> + unsigned int irq_bit_recv_not_empty;
> + unsigned int irq_bit_send_empty;
> +};
> +
> +int apple_mbox_send(struct apple_mbox *mbox, const struct apple_mbox_msg msg,
> + bool atomic)
> +{
> + unsigned long flags;
> + int ret;
> + u32 mbox_ctrl;
> + long t;
> +
> + spin_lock_irqsave(&mbox->tx_lock, flags);
> + mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->a2i_control);
> +
> + while (mbox_ctrl & mbox->hw->control_full) {
> + if (atomic) {
> + ret = readl_poll_timeout_atomic(
> + mbox->regs + mbox->hw->a2i_control, mbox_ctrl,
> + !(mbox_ctrl & mbox->hw->control_full), 100,
> + APPLE_MBOX_TX_TIMEOUT * 1000);
> +
> + if (ret) {
> + spin_unlock_irqrestore(&mbox->tx_lock, flags);
> + return ret;
> + }
> +
> + break;
> + }
> + /*
> + * The interrupt is level triggered and will keep firing as long as the
> + * FIFO is empty. It will also keep firing if the FIFO was empty
> + * at any point in the past until it has been acknowledged at the
> + * mailbox level. By acknowledging it here we can ensure that we will
> + * only get the interrupt once the FIFO has been cleared again.
> + * If the FIFO is already empty before the ack it will fire again
> + * immediately after the ack.
> + */
> + if (mbox->hw->has_irq_controls) {
> + writel_relaxed(mbox->hw->irq_bit_send_empty,
> + mbox->regs + mbox->hw->irq_ack);
> + }
> + enable_irq(mbox->irq_send_empty);
> + reinit_completion(&mbox->tx_empty);
> + spin_unlock_irqrestore(&mbox->tx_lock, flags);
> +
> + t = wait_for_completion_interruptible_timeout(
> + &mbox->tx_empty,
> + msecs_to_jiffies(APPLE_MBOX_TX_TIMEOUT));
> + if (t < 0)
> + return t;
> + else if (t == 0)
> + return -ETIMEDOUT;
> +
> + spin_lock_irqsave(&mbox->tx_lock, flags);
> + mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->a2i_control);
> + }
> +
> + writeq_relaxed(msg.msg0, mbox->regs + mbox->hw->a2i_send0);
> + writeq_relaxed(FIELD_PREP(APPLE_MBOX_MSG1_MSG, msg.msg1),
> + mbox->regs + mbox->hw->a2i_send1);
> +
> + spin_unlock_irqrestore(&mbox->tx_lock, flags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(apple_mbox_send);
> +
> +static irqreturn_t apple_mbox_send_empty_irq(int irq, void *data)
> +{
> + struct apple_mbox *mbox = data;
> +
> + /*
> + * We don't need to acknowledge the interrupt at the mailbox level
> + * here even if supported by the hardware. It will keep firing but that
> + * doesn't matter since it's disabled at the main interrupt controller.
> + * apple_mbox_send will acknowledge it before enabling
> + * it at the main controller again.
> + */
> + spin_lock(&mbox->tx_lock);
> + disable_irq_nosync(mbox->irq_send_empty);
> + complete(&mbox->tx_empty);
> + spin_unlock(&mbox->tx_lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int apple_mbox_poll_locked(struct apple_mbox *mbox)
> +{
> + struct apple_mbox_msg msg;
> + int ret = 0;
> +
> + u32 mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->i2a_control);
> +
> + while (!(mbox_ctrl & mbox->hw->control_empty)) {
> + msg.msg0 = readq_relaxed(mbox->regs + mbox->hw->i2a_recv0);
> + msg.msg1 = FIELD_GET(
> + APPLE_MBOX_MSG1_MSG,
> + readq_relaxed(mbox->regs + mbox->hw->i2a_recv1));
> +
> + mbox->rx(mbox, msg, mbox->cookie);
> + ret++;
> + mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->i2a_control);
> + }
> +
> + /*
> + * The interrupt will keep firing even if there are no more messages
> + * unless we also acknowledge it at the mailbox level here.
> + * There's no race if a message comes in between the check in the while
> + * loop above and the ack below: If a new messages arrives inbetween
> + * those two the interrupt will just fire again immediately after the
> + * ack since it's level triggered.
> + */
> + if (mbox->hw->has_irq_controls) {
> + writel_relaxed(mbox->hw->irq_bit_recv_not_empty,
> + mbox->regs + mbox->hw->irq_ack);
> + }
> +
> + return ret;
> +}
> +
> +static irqreturn_t apple_mbox_recv_irq(int irq, void *data)
> +{
> + struct apple_mbox *mbox = data;
> +
> + spin_lock(&mbox->rx_lock);
> + apple_mbox_poll_locked(mbox);
> + spin_unlock(&mbox->rx_lock);
> +
> + return IRQ_HANDLED;
> +}
> +
> +int apple_mbox_poll(struct apple_mbox *mbox)
> +{
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(&mbox->rx_lock, flags);
> + ret = apple_mbox_poll_locked(mbox);
> + spin_unlock_irqrestore(&mbox->rx_lock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(apple_mbox_poll);
> +
> +int apple_mbox_start(struct apple_mbox *mbox)
> +{
> + int ret;
> +
> + if (mbox->active)
> + return 0;
> +
> + ret = pm_runtime_resume_and_get(mbox->dev);
> + if (ret)
> + return ret;
> +
> + /*
> + * Only some variants of this mailbox HW provide interrupt control
> + * at the mailbox level. We therefore need to handle enabling/disabling
> + * interrupts at the main interrupt controller anyway for hardware that
> + * doesn't. Just always keep the interrupts we care about enabled at
> + * the mailbox level so that both hardware revisions behave almost
> + * the same.
> + */
> + if (mbox->hw->has_irq_controls) {
> + writel_relaxed(mbox->hw->irq_bit_recv_not_empty |
> + mbox->hw->irq_bit_send_empty,
> + mbox->regs + mbox->hw->irq_enable);
> + }
> +
> + enable_irq(mbox->irq_recv_not_empty);
> + mbox->active = true;
> + return 0;
> +}
> +EXPORT_SYMBOL(apple_mbox_start);
> +
> +void apple_mbox_stop(struct apple_mbox *mbox)
> +{
> + if (!mbox->active)
> + return;
> +
> + mbox->active = false;
> + disable_irq(mbox->irq_recv_not_empty);
> + pm_runtime_mark_last_busy(mbox->dev);
> + pm_runtime_put_autosuspend(mbox->dev);
> +}
> +EXPORT_SYMBOL(apple_mbox_stop);
> +
> +struct apple_mbox *apple_mbox_get(struct device *dev, int index)
> +{
> + struct of_phandle_args args;
> + struct platform_device *pdev;
> + struct apple_mbox *mbox;
> + int ret;
> +
> + ret = of_parse_phandle_with_args(dev->of_node, "mboxes", "#mbox-cells",
> + index, &args);
> + if (ret || !args.np)
> + return ERR_PTR(ret);
> +
> + pdev = of_find_device_by_node(args.np);
> + of_node_put(args.np);
> +
> + if (!pdev)
> + return ERR_PTR(EPROBE_DEFER);
> +
> + mbox = platform_get_drvdata(pdev);
> + if (!mbox)
> + return ERR_PTR(EPROBE_DEFER);
> +
> + if (!device_link_add(dev, &pdev->dev, DL_FLAG_AUTOREMOVE_CONSUMER))
> + return ERR_PTR(ENODEV);
> +
> + return mbox;
> +}
> +EXPORT_SYMBOL(apple_mbox_get);
> +
> +struct apple_mbox *apple_mbox_get_byname(struct device *dev, const char *name)
> +{
> + int index;
> +
> + index = of_property_match_string(dev->of_node, "mbox-names", name);
> + if (index < 0)
> + return ERR_PTR(index);
> +
> + return apple_mbox_get(dev, index);
> +}
> +EXPORT_SYMBOL(apple_mbox_get_byname);
> +
> +static int apple_mbox_probe(struct platform_device *pdev)
> +{
> + int ret;
> + char *irqname;
> + struct apple_mbox *mbox;
> + struct device *dev = &pdev->dev;
> +
> + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> + if (!mbox)
> + return -ENOMEM;
> +
> + mbox->dev = &pdev->dev;
> + mbox->hw = of_device_get_match_data(dev);
> + if (!mbox->hw)
> + return -EINVAL;
> +
> + mbox->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(mbox->regs))
> + return PTR_ERR(mbox->regs);
> +
> + mbox->irq_recv_not_empty =
> + platform_get_irq_byname(pdev, "recv-not-empty");
> + if (mbox->irq_recv_not_empty < 0)
> + return -ENODEV;
> +
> + mbox->irq_send_empty = platform_get_irq_byname(pdev, "send-empty");
> + if (mbox->irq_send_empty < 0)
> + return -ENODEV;
> +
> + spin_lock_init(&mbox->rx_lock);
> + spin_lock_init(&mbox->tx_lock);
> + init_completion(&mbox->tx_empty);
> +
> + irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-recv", dev_name(dev));
> + if (!irqname)
> + return -ENOMEM;
> +
> + ret = devm_request_irq(dev, mbox->irq_recv_not_empty,
> + apple_mbox_recv_irq,
> + IRQF_NO_AUTOEN | IRQF_NO_SUSPEND, irqname, mbox);
> + if (ret)
> + return ret;
> +
> + irqname = devm_kasprintf(dev, GFP_KERNEL, "%s-send", dev_name(dev));
> + if (!irqname)
> + return -ENOMEM;
> +
> + ret = devm_request_irq(dev, mbox->irq_send_empty,
> + apple_mbox_send_empty_irq,
> + IRQF_NO_AUTOEN | IRQF_NO_SUSPEND, irqname, mbox);
> + if (ret)
> + return ret;
> +
> + ret = devm_pm_runtime_enable(dev);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, mbox);
> + return 0;
> +}
> +
> +static const struct apple_mbox_hw apple_mbox_asc_hw = {
> + .control_full = APPLE_ASC_MBOX_CONTROL_FULL,
> + .control_empty = APPLE_ASC_MBOX_CONTROL_EMPTY,
> +
> + .a2i_control = APPLE_ASC_MBOX_A2I_CONTROL,
> + .a2i_send0 = APPLE_ASC_MBOX_A2I_SEND0,
> + .a2i_send1 = APPLE_ASC_MBOX_A2I_SEND1,
> +
> + .i2a_control = APPLE_ASC_MBOX_I2A_CONTROL,
> + .i2a_recv0 = APPLE_ASC_MBOX_I2A_RECV0,
> + .i2a_recv1 = APPLE_ASC_MBOX_I2A_RECV1,
> +
> + .has_irq_controls = false,
> +};
> +
> +static const struct apple_mbox_hw apple_mbox_m3_hw = {
> + .control_full = APPLE_M3_MBOX_CONTROL_FULL,
> + .control_empty = APPLE_M3_MBOX_CONTROL_EMPTY,
> +
> + .a2i_control = APPLE_M3_MBOX_A2I_CONTROL,
> + .a2i_send0 = APPLE_M3_MBOX_A2I_SEND0,
> + .a2i_send1 = APPLE_M3_MBOX_A2I_SEND1,
> +
> + .i2a_control = APPLE_M3_MBOX_I2A_CONTROL,
> + .i2a_recv0 = APPLE_M3_MBOX_I2A_RECV0,
> + .i2a_recv1 = APPLE_M3_MBOX_I2A_RECV1,
> +
> + .has_irq_controls = true,
> + .irq_enable = APPLE_M3_MBOX_IRQ_ENABLE,
> + .irq_ack = APPLE_M3_MBOX_IRQ_ACK,
> + .irq_bit_recv_not_empty = APPLE_M3_MBOX_IRQ_I2A_NOT_EMPTY,
> + .irq_bit_send_empty = APPLE_M3_MBOX_IRQ_A2I_EMPTY,
> +};
> +
> +static const struct of_device_id apple_mbox_of_match[] = {
> + { .compatible = "apple,asc-mailbox-v4", .data = &apple_mbox_asc_hw },
> + { .compatible = "apple,m3-mailbox-v2", .data = &apple_mbox_m3_hw },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, apple_mbox_of_match);
> +
> +static struct platform_driver apple_mbox_driver = {
> + .driver = {
> + .name = "apple-mailbox",
> + .of_match_table = apple_mbox_of_match,
> + },
> + .probe = apple_mbox_probe,
> +};
> +module_platform_driver(apple_mbox_driver);
> +
> +MODULE_LICENSE("Dual MIT/GPL");
> +MODULE_AUTHOR("Sven Peter <[email protected]>");
> +MODULE_DESCRIPTION("Apple Mailbox driver");
> diff --git a/drivers/soc/apple/mailbox.h b/drivers/soc/apple/mailbox.h
> new file mode 100644
> index 000000000000..f73a8913da95
> --- /dev/null
> +++ b/drivers/soc/apple/mailbox.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> +/*
> + * Apple mailbox message format
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#ifndef _APPLE_MAILBOX_H_
> +#define _APPLE_MAILBOX_H_
> +
> +#include <linux/device.h>
> +#include <linux/types.h>
> +
> +/* encodes a single 96bit message sent over the single channel */
> +struct apple_mbox_msg {
> + u64 msg0;
> + u32 msg1;
> +};
> +
> +struct apple_mbox {
> + struct device *dev;
> + void __iomem *regs;
> + const struct apple_mbox_hw *hw;
> + bool active;
> +
> + int irq_recv_not_empty;
> + int irq_send_empty;
> +
> + spinlock_t rx_lock;
> + spinlock_t tx_lock;
> +
> + struct completion tx_empty;
> +
> + /** Receive callback for incoming messages */
> + void (*rx)(struct apple_mbox *mbox, struct apple_mbox_msg msg, void *cookie);
> + void *cookie;
> +};
> +
> +struct apple_mbox *apple_mbox_get(struct device *dev, int index);
> +struct apple_mbox *apple_mbox_get_byname(struct device *dev, const char *name);
> +
> +int apple_mbox_start(struct apple_mbox *mbox);
> +void apple_mbox_stop(struct apple_mbox *mbox);
> +int apple_mbox_poll(struct apple_mbox *mbox);
> +int apple_mbox_send(struct apple_mbox *mbox, struct apple_mbox_msg msg,
> + bool atomic);
> +
> +#endif
>
> --
> 2.40.0
>
>
This resolves the firmware crashes related to queue overflow that I hit. Thank you for fixing this, Hector!
Series is
Acked-by: Alyssa Rosenzweig <[email protected]>
[I'd give a stronger tag but I'm way out of my depths here for review. ++ on the ideas though.]
March 28, 2023 9:14 AM, "Hector Martin" <[email protected]> wrote:
> Once upon a time, Apple machines had some mailbox hardware, and we had
> to write a driver for it. And since it was a mailbox, it felt natural to
> use the Linux mailbox subsystem.
>
> More than a year later, it has become evident that was not the right
> decision.
>
> Linux driver class subsystems generally exist for a few purposes:
> 1. To allow mixing and matching generic producers and consumers.
> 2. To implement common code that is likely to be shared across drivers,
> and do so correctly so correct code only has to be written once.
> 3. To force drivers into a "correct" design, such that driver authors
> avoid common pitfalls.
>
> The mailbox subsystem does not do any of the above for us:
> 1. Mailbox hardware is not generic; "mailbox" is a vague idea, not a
> standard for communication. Almost all mailbox consumers are tied to
> one or a few producers. There is practically no mixing and matching
> possible. We have one (1) consumer subsystem (RTKit) talking to one
> (1) mailbox driver (apple-mailbox). We might have a second consumer
> in the future (SEP), but there will still be no useful
> combinatronics with other drivers.
> 2. The mailbox subsystem implements a bunch of common code for queuing,
> but we don't need that because our hardware has hardware queues. It
> also implements a bunch of common code for supporting multiple
> channels, but we don't need that because our hardware only has one
> channel (it has "endpoints" but those are just tags that are part of
> the message). On top of this, the mailbox subsystem makes design
> decisions unsuitable for our use case. Its queuing implementation
> has a fixed queue size and fails sends when full instead of pushing
> back by blocking, which is completely unsuitable for high-traffic
> mailboxes with hard reliability requirements, such as ours. We've
> also run into multiple issues around using mailbox in an atomic
> context (required for SMC reboot/shutdown requests).
> 3. Mailbox doesn't really do much for us as far as driver design.
> If anything, it has been forcing us to add extra workarounds for the
> impedance mismatches between the subsystem core and the hardware.
> Other drivers already are inconsistent in how they use the mailbox
> core, because the documentation is unclear on various details.
>
> The interface for mailboxes is very simple - basically just a send() and
> a receive callback. This series quite literally just rips out the
> middleman, and connects both sides together directly. There just isn't
> anything useful the mailbox common code is doing for us - it's just a
> pile of complexity in the middle that adds bugs, impedance mismatches,
> overhead, and offers no extra features we can use.
>
> This series offers:
>
> - A modest reduction in overall code size (-27 net lines excluding #1).
> - Fixes a pile of bugs related to using the mailbox subsystem and its
> quirks and limitations (race conditions when messages are already in
> the queue on startup, atomic issues, the list goes on).
> - Adds runtime-PM support.
> - Adds support for the FIFOs in the mailbox hardware, improving
> performance.
> - Simplifies code by removing extraneous memory allocations (the
> mailbox subsystem requires consumers to pass pointers to messages,
> instead of inlining them, even though messages are usually only one or
> two registers in size) and the requisite cleanup/freeing in the
> completion path.
>
> In addition, it paves the way for future Apple-specific mailbox
> optimizations, such as adding the ability to de-duplicate message sends
> if the same message is already known to be in the FIFO (which can be
> done by keeping a rolling history of recently sent messages). This is
> useful for doorbell-style messages, which are redundant to send more
> than once if not yet processed.
>
> Apple Silicon platforms use these mailboxes pervasively, including as
> part of the GPU submission hot path. On top of that, bad interactions
> with firmware coprocessors can cause immediate lockups or crashes with
> no recovery possible but a reboot. Our requirements for reliability and
> performance are probably much higher than the average mailbox user, and
> we'd much rather not have a bunch of common code getting in the way of
> performance profiling and future optimization. It doesn't make much
> sense for the mailbox subsystem either, since solving these issues would
> require major refactoring that is unlikely to provide significant
> benefit to most other users.
>
> So let's just call usage of the mailbox subsystem a failed experiment,
> and move the driver into soc/apple, where we can control the API and can
> add whatever peculiarities we need for our mailboxes. Farewell, mailbox.
>
> There are no changes to the DT bindings. This driver has been shipping
> in Asahi stable kernel packages for a week, with no regressions
> reported by any users.
>
> As an additional non-kernel-related benefit, this introduces a direct
> module dependency between consumers and the mailbox producer. This, in
> turn, is in the critical path for the NVMe driver on these platforms.
> Prior to this series, we had to have custom initramfs hooks to add
> apple-mailbox to distro initramfses, and accidentally removing these
> hooks would result in a completely unbootable system (there is no way
> for standard initramfs machinery to detect soft consumer/producer
> relationships like this, they usually just go looking for block device
> modules and their direct dependencies). We still need the initramfs
> hooks for other things, but with this change, completely removing all
> Apple-related initramfs hooks will at least result in a *bootable*
> system so you can fix the problem. This has already bit several users,
> and it also means many more distros have a chance of working out of the
> box (enough to let you install extra stuff) on these platforms, instead
> of having a hard requirement that *every single distro* fix up their
> initramfs generation in order to even boot/install on these platforms at
> all.
>
> Jassi: Ideally I'd like to get an ack on this and merge it all through
> asahi-soc, so we don't have to play things patch-by-patch across
> multiple merge cycles to avoid potentially broken intermediate states.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> Hector Martin (5):
> soc: apple: rtkit: Get rid of apple_rtkit_send_message_wait
> soc: apple: mailbox: Add ASC/M3 mailbox driver
> soc: apple: rtkit: Port to the internal mailbox driver
> mailbox: apple: Delete driver
> soc: apple: mailbox: Rename config symbol to APPLE_MAILBOX
>
> MAINTAINERS | 2 -
> drivers/mailbox/Kconfig | 12 -
> drivers/mailbox/Makefile | 2 -
> drivers/mailbox/apple-mailbox.c | 441 -------------------------------------
> drivers/soc/apple/Kconfig | 15 +-
> drivers/soc/apple/Makefile | 3 +
> drivers/soc/apple/mailbox.c | 434 ++++++++++++++++++++++++++++++++++++
> drivers/soc/apple/mailbox.h | 48 ++++
> drivers/soc/apple/rtkit-internal.h | 8 +-
> drivers/soc/apple/rtkit.c | 133 +++--------
> include/linux/apple-mailbox.h | 19 --
> include/linux/soc/apple/rtkit.h | 18 --
> 12 files changed, 529 insertions(+), 606 deletions(-)
> ---
> base-commit: bdfe6de2695c5bccc663a5a7d530f81925d8bc10
> change-id: 20230328-soc-mailbox-3cb6bb2b0b2d
>
> Best regards,
> --
> Hector Martin <[email protected]>
Hi Hector,
I love your patch! Yet something to improve:
[auto build test ERROR on bdfe6de2695c5bccc663a5a7d530f81925d8bc10]
url: https://github.com/intel-lab-lkp/linux/commits/Hector-Martin/soc-apple-rtkit-Get-rid-of-apple_rtkit_send_message_wait/20230328-211648
base: bdfe6de2695c5bccc663a5a7d530f81925d8bc10
patch link: https://lore.kernel.org/r/20230328-soc-mailbox-v1-5-3953814532fd%40marcan.st
patch subject: [PATCH 5/5] soc: apple: mailbox: Rename config symbol to APPLE_MAILBOX
config: ia64-allmodconfig (https://download.01.org/0day-ci/archive/20230329/[email protected]/config)
compiler: ia64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/d0addf95095d935cdd5940101fbf1b1594b08158
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Hector-Martin/soc-apple-rtkit-Get-rid-of-apple_rtkit_send_message_wait/20230328-211648
git checkout d0addf95095d935cdd5940101fbf1b1594b08158
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=ia64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/soc/apple/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
| Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
All errors (new ones prefixed by >>):
drivers/soc/apple/mailbox.c: In function 'apple_mbox_send':
>> drivers/soc/apple/mailbox.c:151:24: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
151 | writeq_relaxed(FIELD_PREP(APPLE_MBOX_MSG1_MSG, msg.msg1),
| ^~~~~~~~~~
drivers/soc/apple/mailbox.c: In function 'apple_mbox_poll_locked':
>> drivers/soc/apple/mailbox.c:188:28: error: implicit declaration of function 'FIELD_GET' [-Werror=implicit-function-declaration]
188 | msg.msg1 = FIELD_GET(
| ^~~~~~~~~
cc1: some warnings being treated as errors
vim +/FIELD_PREP +151 drivers/soc/apple/mailbox.c
8b654b5034baba0 Hector Martin 2023-03-28 95
8b654b5034baba0 Hector Martin 2023-03-28 96 int apple_mbox_send(struct apple_mbox *mbox, const struct apple_mbox_msg msg,
8b654b5034baba0 Hector Martin 2023-03-28 97 bool atomic)
8b654b5034baba0 Hector Martin 2023-03-28 98 {
8b654b5034baba0 Hector Martin 2023-03-28 99 unsigned long flags;
8b654b5034baba0 Hector Martin 2023-03-28 100 int ret;
8b654b5034baba0 Hector Martin 2023-03-28 101 u32 mbox_ctrl;
8b654b5034baba0 Hector Martin 2023-03-28 102 long t;
8b654b5034baba0 Hector Martin 2023-03-28 103
8b654b5034baba0 Hector Martin 2023-03-28 104 spin_lock_irqsave(&mbox->tx_lock, flags);
8b654b5034baba0 Hector Martin 2023-03-28 105 mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->a2i_control);
8b654b5034baba0 Hector Martin 2023-03-28 106
8b654b5034baba0 Hector Martin 2023-03-28 107 while (mbox_ctrl & mbox->hw->control_full) {
8b654b5034baba0 Hector Martin 2023-03-28 108 if (atomic) {
8b654b5034baba0 Hector Martin 2023-03-28 109 ret = readl_poll_timeout_atomic(
8b654b5034baba0 Hector Martin 2023-03-28 110 mbox->regs + mbox->hw->a2i_control, mbox_ctrl,
8b654b5034baba0 Hector Martin 2023-03-28 111 !(mbox_ctrl & mbox->hw->control_full), 100,
8b654b5034baba0 Hector Martin 2023-03-28 112 APPLE_MBOX_TX_TIMEOUT * 1000);
8b654b5034baba0 Hector Martin 2023-03-28 113
8b654b5034baba0 Hector Martin 2023-03-28 114 if (ret) {
8b654b5034baba0 Hector Martin 2023-03-28 115 spin_unlock_irqrestore(&mbox->tx_lock, flags);
8b654b5034baba0 Hector Martin 2023-03-28 116 return ret;
8b654b5034baba0 Hector Martin 2023-03-28 117 }
8b654b5034baba0 Hector Martin 2023-03-28 118
8b654b5034baba0 Hector Martin 2023-03-28 119 break;
8b654b5034baba0 Hector Martin 2023-03-28 120 }
8b654b5034baba0 Hector Martin 2023-03-28 121 /*
8b654b5034baba0 Hector Martin 2023-03-28 122 * The interrupt is level triggered and will keep firing as long as the
8b654b5034baba0 Hector Martin 2023-03-28 123 * FIFO is empty. It will also keep firing if the FIFO was empty
8b654b5034baba0 Hector Martin 2023-03-28 124 * at any point in the past until it has been acknowledged at the
8b654b5034baba0 Hector Martin 2023-03-28 125 * mailbox level. By acknowledging it here we can ensure that we will
8b654b5034baba0 Hector Martin 2023-03-28 126 * only get the interrupt once the FIFO has been cleared again.
8b654b5034baba0 Hector Martin 2023-03-28 127 * If the FIFO is already empty before the ack it will fire again
8b654b5034baba0 Hector Martin 2023-03-28 128 * immediately after the ack.
8b654b5034baba0 Hector Martin 2023-03-28 129 */
8b654b5034baba0 Hector Martin 2023-03-28 130 if (mbox->hw->has_irq_controls) {
8b654b5034baba0 Hector Martin 2023-03-28 131 writel_relaxed(mbox->hw->irq_bit_send_empty,
8b654b5034baba0 Hector Martin 2023-03-28 132 mbox->regs + mbox->hw->irq_ack);
8b654b5034baba0 Hector Martin 2023-03-28 133 }
8b654b5034baba0 Hector Martin 2023-03-28 134 enable_irq(mbox->irq_send_empty);
8b654b5034baba0 Hector Martin 2023-03-28 135 reinit_completion(&mbox->tx_empty);
8b654b5034baba0 Hector Martin 2023-03-28 136 spin_unlock_irqrestore(&mbox->tx_lock, flags);
8b654b5034baba0 Hector Martin 2023-03-28 137
8b654b5034baba0 Hector Martin 2023-03-28 138 t = wait_for_completion_interruptible_timeout(
8b654b5034baba0 Hector Martin 2023-03-28 139 &mbox->tx_empty,
8b654b5034baba0 Hector Martin 2023-03-28 140 msecs_to_jiffies(APPLE_MBOX_TX_TIMEOUT));
8b654b5034baba0 Hector Martin 2023-03-28 141 if (t < 0)
8b654b5034baba0 Hector Martin 2023-03-28 142 return t;
8b654b5034baba0 Hector Martin 2023-03-28 143 else if (t == 0)
8b654b5034baba0 Hector Martin 2023-03-28 144 return -ETIMEDOUT;
8b654b5034baba0 Hector Martin 2023-03-28 145
8b654b5034baba0 Hector Martin 2023-03-28 146 spin_lock_irqsave(&mbox->tx_lock, flags);
8b654b5034baba0 Hector Martin 2023-03-28 147 mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->a2i_control);
8b654b5034baba0 Hector Martin 2023-03-28 148 }
8b654b5034baba0 Hector Martin 2023-03-28 149
8b654b5034baba0 Hector Martin 2023-03-28 150 writeq_relaxed(msg.msg0, mbox->regs + mbox->hw->a2i_send0);
8b654b5034baba0 Hector Martin 2023-03-28 @151 writeq_relaxed(FIELD_PREP(APPLE_MBOX_MSG1_MSG, msg.msg1),
8b654b5034baba0 Hector Martin 2023-03-28 152 mbox->regs + mbox->hw->a2i_send1);
8b654b5034baba0 Hector Martin 2023-03-28 153
8b654b5034baba0 Hector Martin 2023-03-28 154 spin_unlock_irqrestore(&mbox->tx_lock, flags);
8b654b5034baba0 Hector Martin 2023-03-28 155
8b654b5034baba0 Hector Martin 2023-03-28 156 return 0;
8b654b5034baba0 Hector Martin 2023-03-28 157 }
8b654b5034baba0 Hector Martin 2023-03-28 158 EXPORT_SYMBOL(apple_mbox_send);
8b654b5034baba0 Hector Martin 2023-03-28 159
8b654b5034baba0 Hector Martin 2023-03-28 160 static irqreturn_t apple_mbox_send_empty_irq(int irq, void *data)
8b654b5034baba0 Hector Martin 2023-03-28 161 {
8b654b5034baba0 Hector Martin 2023-03-28 162 struct apple_mbox *mbox = data;
8b654b5034baba0 Hector Martin 2023-03-28 163
8b654b5034baba0 Hector Martin 2023-03-28 164 /*
8b654b5034baba0 Hector Martin 2023-03-28 165 * We don't need to acknowledge the interrupt at the mailbox level
8b654b5034baba0 Hector Martin 2023-03-28 166 * here even if supported by the hardware. It will keep firing but that
8b654b5034baba0 Hector Martin 2023-03-28 167 * doesn't matter since it's disabled at the main interrupt controller.
8b654b5034baba0 Hector Martin 2023-03-28 168 * apple_mbox_send will acknowledge it before enabling
8b654b5034baba0 Hector Martin 2023-03-28 169 * it at the main controller again.
8b654b5034baba0 Hector Martin 2023-03-28 170 */
8b654b5034baba0 Hector Martin 2023-03-28 171 spin_lock(&mbox->tx_lock);
8b654b5034baba0 Hector Martin 2023-03-28 172 disable_irq_nosync(mbox->irq_send_empty);
8b654b5034baba0 Hector Martin 2023-03-28 173 complete(&mbox->tx_empty);
8b654b5034baba0 Hector Martin 2023-03-28 174 spin_unlock(&mbox->tx_lock);
8b654b5034baba0 Hector Martin 2023-03-28 175
8b654b5034baba0 Hector Martin 2023-03-28 176 return IRQ_HANDLED;
8b654b5034baba0 Hector Martin 2023-03-28 177 }
8b654b5034baba0 Hector Martin 2023-03-28 178
8b654b5034baba0 Hector Martin 2023-03-28 179 static int apple_mbox_poll_locked(struct apple_mbox *mbox)
8b654b5034baba0 Hector Martin 2023-03-28 180 {
8b654b5034baba0 Hector Martin 2023-03-28 181 struct apple_mbox_msg msg;
8b654b5034baba0 Hector Martin 2023-03-28 182 int ret = 0;
8b654b5034baba0 Hector Martin 2023-03-28 183
8b654b5034baba0 Hector Martin 2023-03-28 184 u32 mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->i2a_control);
8b654b5034baba0 Hector Martin 2023-03-28 185
8b654b5034baba0 Hector Martin 2023-03-28 186 while (!(mbox_ctrl & mbox->hw->control_empty)) {
8b654b5034baba0 Hector Martin 2023-03-28 187 msg.msg0 = readq_relaxed(mbox->regs + mbox->hw->i2a_recv0);
8b654b5034baba0 Hector Martin 2023-03-28 @188 msg.msg1 = FIELD_GET(
8b654b5034baba0 Hector Martin 2023-03-28 189 APPLE_MBOX_MSG1_MSG,
8b654b5034baba0 Hector Martin 2023-03-28 190 readq_relaxed(mbox->regs + mbox->hw->i2a_recv1));
8b654b5034baba0 Hector Martin 2023-03-28 191
8b654b5034baba0 Hector Martin 2023-03-28 192 mbox->rx(mbox, msg, mbox->cookie);
8b654b5034baba0 Hector Martin 2023-03-28 193 ret++;
8b654b5034baba0 Hector Martin 2023-03-28 194 mbox_ctrl = readl_relaxed(mbox->regs + mbox->hw->i2a_control);
8b654b5034baba0 Hector Martin 2023-03-28 195 }
8b654b5034baba0 Hector Martin 2023-03-28 196
8b654b5034baba0 Hector Martin 2023-03-28 197 /*
8b654b5034baba0 Hector Martin 2023-03-28 198 * The interrupt will keep firing even if there are no more messages
8b654b5034baba0 Hector Martin 2023-03-28 199 * unless we also acknowledge it at the mailbox level here.
8b654b5034baba0 Hector Martin 2023-03-28 200 * There's no race if a message comes in between the check in the while
8b654b5034baba0 Hector Martin 2023-03-28 201 * loop above and the ack below: If a new messages arrives inbetween
8b654b5034baba0 Hector Martin 2023-03-28 202 * those two the interrupt will just fire again immediately after the
8b654b5034baba0 Hector Martin 2023-03-28 203 * ack since it's level triggered.
8b654b5034baba0 Hector Martin 2023-03-28 204 */
8b654b5034baba0 Hector Martin 2023-03-28 205 if (mbox->hw->has_irq_controls) {
8b654b5034baba0 Hector Martin 2023-03-28 206 writel_relaxed(mbox->hw->irq_bit_recv_not_empty,
8b654b5034baba0 Hector Martin 2023-03-28 207 mbox->regs + mbox->hw->irq_ack);
8b654b5034baba0 Hector Martin 2023-03-28 208 }
8b654b5034baba0 Hector Martin 2023-03-28 209
8b654b5034baba0 Hector Martin 2023-03-28 210 return ret;
8b654b5034baba0 Hector Martin 2023-03-28 211 }
8b654b5034baba0 Hector Martin 2023-03-28 212
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
On Tue, Mar 28, 2023 at 8:14 AM Hector Martin <[email protected]> wrote:
>
> Once upon a time, Apple machines had some mailbox hardware, and we had
> to write a driver for it. And since it was a mailbox, it felt natural to
> use the Linux mailbox subsystem.
>
> More than a year later, it has become evident that was not the right
> decision.
>
> Linux driver class subsystems generally exist for a few purposes:
> 1. To allow mixing and matching generic producers and consumers.
> 2. To implement common code that is likely to be shared across drivers,
> and do so correctly so correct code only has to be written once.
> 3. To force drivers into a "correct" design, such that driver authors
> avoid common pitfalls.
>
The Mailbox subsystem is meant to serve (2) and possibly (3).
We never aimed for (1), we can't... because the firmware on the remote
end is also a part of "local hardware" -- keeping every bit of
hardware the same, if just the f/w changes you may have to change the
linux side driver.
> The mailbox subsystem does not do any of the above for us:
> 1. Mailbox hardware is not generic; "mailbox" is a vague idea, not a
> standard for communication.
>
There _can not_ be a standard mailbox implementation without a
specification -- which doesn't exist.
> Almost all mailbox consumers are tied to
> one or a few producers. There is practically no mixing and matching
> possible. We have one (1) consumer subsystem (RTKit) talking to one
> (1) mailbox driver (apple-mailbox). We might have a second consumer
> in the future (SEP), but there will still be no useful
> combinatronics with other drivers.
>
Sorry I don't follow what you expect.
> 2. The mailbox subsystem implements a bunch of common code for queuing,
> but we don't need that because our hardware has hardware queues. It
> also implements a bunch of common code for supporting multiple
> channels, but we don't need that because our hardware only has one
> channel (it has "endpoints" but those are just tags that are part of
> the message).
>
In note-1, you complain it is not standard/flexible enough, and here
its support for features, that you don't need, become a problem?
> On top of this, the mailbox subsystem makes design
> decisions unsuitable for our use case. Its queuing implementation
> has a fixed queue size and fails sends when full instead of pushing
> back by blocking, which is completely unsuitable for high-traffic
> mailboxes with hard reliability requirements, such as ours. We've
> also run into multiple issues around using mailbox in an atomic
> context (required for SMC reboot/shutdown requests).
>
I don't think you ever shared the issues you were struggling with.
Not to mean there can be no limitation but I knew a platform that ran
a virtual block-device and custom filesystem over the mailbox, and it
was good for a camera product that needs high bandwidth image
transfer.
> 3. Mailbox doesn't really do much for us as far as driver design.
> If anything, it has been forcing us to add extra workarounds for the
> impedance mismatches between the subsystem core and the hardware.
> Other drivers already are inconsistent in how they use the mailbox
> core, because the documentation is unclear on various details.
>
Again, would have helped to know the issues and details you feel missing.
> This series offers:
>
> - A modest reduction in overall code size (-27 net lines excluding #1).
> - Fixes a pile of bugs related to using the mailbox subsystem and its
> quirks and limitations (race conditions when messages are already in
> the queue on startup, atomic issues, the list goes on).
> - Adds runtime-PM support.
> - Adds support for the FIFOs in the mailbox hardware, improving
> performance.
> - Simplifies code by removing extraneous memory allocations (the
> mailbox subsystem requires consumers to pass pointers to messages,
> instead of inlining them, even though messages are usually only one or
> two registers in size) and the requisite cleanup/freeing in the
> completion path.
>
> In addition, it paves the way for future Apple-specific mailbox
> optimizations, such as adding the ability to de-duplicate message sends
> if the same message is already known to be in the FIFO (which can be
> done by keeping a rolling history of recently sent messages). This is
> useful for doorbell-style messages, which are redundant to send more
> than once if not yet processed.
>
> Apple Silicon platforms use these mailboxes pervasively, including as
> part of the GPU submission hot path. On top of that, bad interactions
> with firmware coprocessors can cause immediate lockups or crashes with
> no recovery possible but a reboot. Our requirements for reliability and
> performance are probably much higher than the average mailbox user, and
> we'd much rather not have a bunch of common code getting in the way of
> performance profiling and future optimization. It doesn't make much
> sense for the mailbox subsystem either, since solving these issues would
> require major refactoring that is unlikely to provide significant
> benefit to most other users.
>
> So let's just call usage of the mailbox subsystem a failed experiment,
> and move the driver into soc/apple, where we can control the API and can
> add whatever peculiarities we need for our mailboxes. Farewell, mailbox.
>
> There are no changes to the DT bindings. This driver has been shipping
> in Asahi stable kernel packages for a week, with no regressions
> reported by any users.
>
> As an additional non-kernel-related benefit, this introduces a direct
> module dependency between consumers and the mailbox producer. This, in
> turn, is in the critical path for the NVMe driver on these platforms.
> Prior to this series, we had to have custom initramfs hooks to add
> apple-mailbox to distro initramfses, and accidentally removing these
> hooks would result in a completely unbootable system (there is no way
> for standard initramfs machinery to detect soft consumer/producer
> relationships like this, they usually just go looking for block device
> modules and their direct dependencies). We still need the initramfs
> hooks for other things, but with this change, completely removing all
> Apple-related initramfs hooks will at least result in a *bootable*
> system so you can fix the problem. This has already bit several users,
> and it also means many more distros have a chance of working out of the
> box (enough to let you install extra stuff) on these platforms, instead
> of having a hard requirement that *every single distro* fix up their
> initramfs generation in order to even boot/install on these platforms at
> all.
>
> Jassi: Ideally I'd like to get an ack on this and merge it all through
> asahi-soc, so we don't have to play things patch-by-patch across
> multiple merge cycles to avoid potentially broken intermediate states.
>
Instead of every platform implementing their own message queuing and
handling mechanism and parsing producer-comsumer links from the DT,
there is a reusable code in drivers/mailbox. Which does seem
inadequate if one comes looking for a "standard/generic" mailbox
implementation (again, which can not exist).
And there is a reason the reduction in code with this patchset is
meager -- you anyway have to implement your platform specific stuff.
But if redoing mailbox overall saves you complexity, I am ok with it.
cheers.
On 30/03/2023 01.04, Jassi Brar wrote:
> On Tue, Mar 28, 2023 at 8:14 AM Hector Martin <[email protected]> wrote:
>>
>> Once upon a time, Apple machines had some mailbox hardware, and we had
>> to write a driver for it. And since it was a mailbox, it felt natural to
>> use the Linux mailbox subsystem.
>>
>> More than a year later, it has become evident that was not the right
>> decision.
>>
>> Linux driver class subsystems generally exist for a few purposes:
>> 1. To allow mixing and matching generic producers and consumers.
>> 2. To implement common code that is likely to be shared across drivers,
>> and do so correctly so correct code only has to be written once.
>> 3. To force drivers into a "correct" design, such that driver authors
>> avoid common pitfalls.
>>
> The Mailbox subsystem is meant to serve (2) and possibly (3).
> We never aimed for (1), we can't... because the firmware on the remote
> end is also a part of "local hardware" -- keeping every bit of
> hardware the same, if just the f/w changes you may have to change the
> linux side driver.
Right, I'm just explaining why this isn't like i2c/spi and similar
subsystems. The value proposition is significantly weaker with mailbox
for this reason.
>> 2. The mailbox subsystem implements a bunch of common code for queuing,
>> but we don't need that because our hardware has hardware queues. It
>> also implements a bunch of common code for supporting multiple
>> channels, but we don't need that because our hardware only has one
>> channel (it has "endpoints" but those are just tags that are part of
>> the message).
>>
> In note-1, you complain it is not standard/flexible enough, and here
> its support for features, that you don't need, become a problem?
It has features we don't need that introduce bugs and complexity, while
missing features we *do* need. So yes, it's doubly a problem.
>> On top of this, the mailbox subsystem makes design
>> decisions unsuitable for our use case. Its queuing implementation
>> has a fixed queue size and fails sends when full instead of pushing
>> back by blocking, which is completely unsuitable for high-traffic
>> mailboxes with hard reliability requirements, such as ours. We've
>> also run into multiple issues around using mailbox in an atomic
>> context (required for SMC reboot/shutdown requests).
>>
> I don't think you ever shared the issues you were struggling with.
I did try to send a patch clarifying/cleaning up inconsistent usage of
the atomic codepath in other drivers, and you rejected it. At that point
I gave up in trying to contribute to cleaning up the existing mess,
because you're clearly not interested. I have some downstream fixes for
the atomic codepath and I don't think they even fix all the problems,
because we still run into issues. The design of the mailbox core is just
bizarre and makes it very hard to reason about the corner cases through
the whole queuing business.
It's a big chunk of complexity and bug-prone design and it just doesn't
make any sense for us to spend time on this if cleaning things up is
going to be an uphill battle *and* in the end the subsystem still does
nothing useful for us. It's just using the subsystem for the sake of
using it at that point. It makes no sense.
As for the other issue, there's a giant comment around the queue length
define:
> /*
> * The length of circular buffer for queuing messages from a client.
> * 'msg_count' tracks the number of buffered messages while 'msg_free'
> * is the index where the next message would be buffered.
> * We shouldn't need it too big because every transfer is interrupt
> * triggered and if we have lots of data to transfer, the interrupt
> * latencies are going to be the bottleneck, not the buffer length.
> * Besides, mbox_send_message could be called from atomic context and
> * the client could also queue another message from the notifier 'tx_done'
> * of the last transfer done.
> * REVISIT: If too many platforms see the "Try increasing MBOX_TX_QUEUE_LEN"
> * print, it needs to be taken from config option or somesuch.
> */
> #define MBOX_TX_QUEUE_LEN 20
This issue is clearly known, and it doesn't take a lot of thinking to
realize that *any* queue length limit coupled with hard-fails on message
sends instead of pushback is just unsuitable for many use cases. Maybe
all existing mailbox users have intrinsically synchronous use cases that
keep the queue idle enough, or maybe they're just broken only in corner
cases that haven't come back to the mailbox subsystem yet. Either way,
as far as I'm concerned this is broken by design in the general case.
> Not to mean there can be no limitation but I knew a platform that ran
> a virtual block-device and custom filesystem over the mailbox, and it
> was good for a camera product that needs high bandwidth image
> transfer.
I guess it worked for them, but it's been breaking our GPU use case. So
if it's working for other people, I guess that's fine. But it's
definitely not working for us, and I'm not inclined to try to fix the
issues if nobody else has a problem.
Working on common code has the inherent risk that any changes can break
other users and I have no way to test every other mailbox user. There
are real *costs* associated with having common code, especially for
boutique things like mailbox which are highly heterogeneous and used on
all kinds of weird systems no single developer can hope to have access to.
So if you say it's working well for other people, all the more reason
for us to move away and leave them alone instead of trying to make major
changes to fix everything that isn't working for us and risk breaking
others.
>> Jassi: Ideally I'd like to get an ack on this and merge it all through
>> asahi-soc, so we don't have to play things patch-by-patch across
>> multiple merge cycles to avoid potentially broken intermediate states.
>>
> Instead of every platform implementing their own message queuing and
> handling mechanism and parsing producer-comsumer links from the DT,
> there is a reusable code in drivers/mailbox.
As I said, we don't need nor want message queuing (yes, this is the bulk
of the complexity of the subsystem and really the source of a lot of the
pain, especially once you start throwing atomic into the mix). Other
mailbox hardware might, and that's fine. It's just not for us.
Especially not if it falls over when the queue gets full like it does.
I'm not saying the mailbox subsystem shouldn't exist, I'm saying it
might be a good idea as it stands for *some* mailbox
producers/consumers/use cases, but not *all*, and in this case, not ours.
As for the DT links, that's ~25 lines of code.
> And there is a reason the reduction in code with this patchset is
> meager -- you anyway have to implement your platform specific stuff.
Think about it for a second. We are ceasing use of the subsystem, which
under any reasonable expectation would require us to *add* code to
duplicate functionality. Indeed there's one new small function to deal
with the OF phandle lookup. And there's also a whole new header file
with prototypes that are a facsimile of the core mailbox API too. But
overall the total LOC is down, because we more than make that up by
removing overhead caused by having to bend to the wills of the subsystem
and work around its issues (and we'd be removing even more if the
upstream driver already had the new features like runtime-PM and
workarounds for more issues).
> But if redoing mailbox overall saves you complexity, I am ok with it.
Is that an ack? :-)
- Hector
On Wed, Mar 29, 2023 at 5:53 PM Hector Martin <[email protected]> wrote:
> On 30/03/2023 01.04, Jassi Brar wrote:
> >> On top of this, the mailbox subsystem makes design
> >> decisions unsuitable for our use case. Its queuing implementation
> >> has a fixed queue size and fails sends when full instead of pushing
> >> back by blocking, which is completely unsuitable for high-traffic
> >> mailboxes with hard reliability requirements, such as ours. We've
> >> also run into multiple issues around using mailbox in an atomic
> >> context (required for SMC reboot/shutdown requests).
> >>
> > I don't think you ever shared the issues you were struggling with.
>
> I did try to send a patch clarifying/cleaning up inconsistent usage of
> the atomic codepath in other drivers, and you rejected it. At that point
> I gave up in trying to contribute to cleaning up the existing mess,
> because you're clearly not interested.
>
You mean https://lore.kernel.org/lkml/[email protected]/
Now I see where this code-rage comes from.
But let me clarify even more...
You do not kill some api just because you don't need that and/or you
think that is "stupid" because you can't see past your own use-case.
Peek'ing is a valid usecase. If you need Polling, that does not
mean other platforms are broken to need to Peek. You can not declare
all platforms must be able to fetch data from remote in atomic
context. Think of a platform that must do some sleepy calls to fetch
data ? Or a large buffer copy is involved.
If your platform can read and pass-on data in atomic context, you
can still implement that around the existing peek api (ok a few extra
loc involved). Even if we see that the api must provide polling, we
may add a new callback or 'overload' peek.... but still you can not
kill peek. If you do, I am sure another revolutionary will arise in
few months finding the atomic-read requirement "stupid" and either
revert poll or reintroduce peek :)
>
> As for the other issue, there's a giant comment around the queue length
> define:
>
> > /*
> > * The length of circular buffer for queuing messages from a client.
> > * 'msg_count' tracks the number of buffered messages while 'msg_free'
> > * is the index where the next message would be buffered.
> > * We shouldn't need it too big because every transfer is interrupt
> > * triggered and if we have lots of data to transfer, the interrupt
> > * latencies are going to be the bottleneck, not the buffer length.
> > * Besides, mbox_send_message could be called from atomic context and
> > * the client could also queue another message from the notifier 'tx_done'
> > * of the last transfer done.
> > * REVISIT: If too many platforms see the "Try increasing MBOX_TX_QUEUE_LEN"
> > * print, it needs to be taken from config option or somesuch.
> > */
> > #define MBOX_TX_QUEUE_LEN 20
>
> This issue is clearly known, and it doesn't take a lot of thinking to
> realize that *any* queue length limit coupled with hard-fails on message
> sends instead of pushback is just unsuitable for many use cases. Maybe
> all existing mailbox users have intrinsically synchronous use cases that
> keep the queue idle enough, or maybe they're just broken only in corner
> cases that haven't come back to the mailbox subsystem yet. Either way,
> as far as I'm concerned this is broken by design in the general case.
>
You may be surprised but I do understand hardcoding limits on buffer
size is taboo.... unless benefits outweigh fingerpointing :)
1) Using an array here greatly simplifies the code by avoiding code to
dynamically shrink/expand the linked list while constrained by the
atomic context. Using array with head and tail indices is a fast and
simplest way to implement a ring buffer. I also intented the api to
have least footprint on the throughput and resources (my own initial
usecase was high speed 4k image transfer).
2) The api relies on last_tx_done() to make sure we submit data only
when we have an all-clear ... which is a platform specific way to
ensure signal will physically reach the remote (whether data is
accepted or not is upto the upper layer protocol and that's why it is
recommended to pass pointer to data, rather than data as the signal).
The way api is recommended (not required) to be used, the limit on
TX_QUEUE_LEN(20), is not impactful beyond the fifo size of the
controller. Though I am open to idea of seeing if tx failure should be
considered a possiblity even after last_tx_done.
Iirc on lkml, people have reported using 1000s tx calls per second
within this queue limit. I don't know how you tried to interpret that
limit but would have helped to know your issue.
>
> > But if redoing mailbox overall saves you complexity, I am ok with it.
>
> Is that an ack? :-)
>
You sound like being trapped in a bad marriage with mailbox :) And
I really don't want you to stay in a rewardless situation --- I have
actually asked some platforms during RFCs if mailbox is really useful
for them (usually SMC/HVC based useage), but they found use.
Please make sure it is not just code-rage of your patchset being
rejected, and indeed there are things you can't do with the api.
Because the api can not have Zero impact on any platform's
implementation and my ack here could be used as a precedent for every
platform to implement their own tx/rx queues and dt handling and move
into drivers/soc/. A couple years later someone will see it doesn't
make sense every platform is doing the same thing in driver/soc/ and
maybe it s a good idea to have some drivers/mailbox/ to hold the
common code.
I am also aware I am just a volunteer at mailbox and can not dictate
what you do with your platform. So, is there anything like
Neither-acked-nor-objected-but-left-to-soc-by ? ;)
cheers.
On 31/03/2023 01.35, Jassi Brar wrote:
> On Wed, Mar 29, 2023 at 5:53 PM Hector Martin <[email protected]> wrote:
>> On 30/03/2023 01.04, Jassi Brar wrote:
>
>>>> On top of this, the mailbox subsystem makes design
>>>> decisions unsuitable for our use case. Its queuing implementation
>>>> has a fixed queue size and fails sends when full instead of pushing
>>>> back by blocking, which is completely unsuitable for high-traffic
>>>> mailboxes with hard reliability requirements, such as ours. We've
>>>> also run into multiple issues around using mailbox in an atomic
>>>> context (required for SMC reboot/shutdown requests).
>>>>
>>> I don't think you ever shared the issues you were struggling with.
>>
>> I did try to send a patch clarifying/cleaning up inconsistent usage of
>> the atomic codepath in other drivers, and you rejected it. At that point
>> I gave up in trying to contribute to cleaning up the existing mess,
>> because you're clearly not interested.
>>
> You mean https://lore.kernel.org/lkml/[email protected]/
> Now I see where this code-rage comes from.
>
> But let me clarify even more...
> You do not kill some api just because you don't need that and/or you
> think that is "stupid" because you can't see past your own use-case.
It is general Linux kernel policy not to have internal APIs with zero
users. The Rust folks get pushback all the time for upstreaming stuff
piecewise even though in that case there are known, upcoming,
in-the-pipeline users (we do that too with rtkit but we always have
upcoming users downstream and we're small enough nobody notices and
complains :P). Having dead APIs that nobody uses and nobody can point at
an upcoming use case for is technical debt. That's why my first patch in
this series cleans up one of those on our side.
>> This issue is clearly known, and it doesn't take a lot of thinking to
>> realize that *any* queue length limit coupled with hard-fails on message
>> sends instead of pushback is just unsuitable for many use cases. Maybe
>> all existing mailbox users have intrinsically synchronous use cases that
>> keep the queue idle enough, or maybe they're just broken only in corner
>> cases that haven't come back to the mailbox subsystem yet. Either way,
>> as far as I'm concerned this is broken by design in the general case.
>>
> You may be surprised but I do understand hardcoding limits on buffer
> size is taboo.... unless benefits outweigh fingerpointing :)
Using a fixed size buffer is not the problem, having no blocking
mechanism when it gets full is the problem.
> 2) The api relies on last_tx_done() to make sure we submit data only
> when we have an all-clear ...
That's not the issue, the issue is putting stuff *into* the queue, not
taking it *out* of the queue and sending it to the hardware.
> which is a platform specific way to
> ensure signal will physically reach the remote (whether data is
> accepted or not is upto the upper layer protocol and that's why it is
> recommended to pass pointer to data, rather than data as the signal).
> The way api is recommended (not required) to be used, the limit on
> TX_QUEUE_LEN(20), is not impactful beyond the fifo size of the
> controller. Though I am open to idea of seeing if tx failure should be
> considered a possiblity even after last_tx_done.
If I do this:
for (int i = 0; i < 30; i++) {
mbox_send_message(...);
}
Then, unless the remote is fast enough to accept messages faster than
the CPU can send them, some of those sends will fail and refuse to send
data, once the subsystem side queue is full.
That is broken because it either loses data or forces the user to
implement retry poll loops, neither of which is appropriate. The mailbox
subsystem knows when the hardware can send data, it can properly block
the send on that signal (which is exactly what my refactor in this
series does when the hardware queue gets full).
If we instead wait for the tx completion stuff before sending, then that
defeats the point of having a queue because you'd be waiting for each
prior message before sending a new one. And then you need to keep track
of the last completion. And it requires a global serialization on the
client side anyway unless you can guarantee you have less than
QUEUE_SIZE clients. And you still have the issue of having to keep the
message data around until that completion fires, which is more code and
allocator overhead over just passing it inline, since it's a tiny amount
of data. Etc etc etc.
It is a bad API, using it properly and reliably requires basically
re-implementing part of the subsystem logic in the consumer to work
around the issues.
> Iirc on lkml, people have reported using 1000s tx calls per second
> within this queue limit. I don't know how you tried to interpret that
> limit but would have helped to know your issue.
For reference: Our GPU benchmarks will easily hit 18000+ TX calls per
second through mailbox, even more for some corner cases (this is why I
want to implement coalescing when the HW queue already has identical
doorbells, to reduce that). More importantly, although the GPU side
firmware is usually fast at processing this (it has an IRQ handler and
its own doorbell coalescing), when GPU faults or errors happen it has
latency spikes, and then we *must* block mailbox sends until it is ready
to handle messages again. Dropping messages on the floor is not an
option. This *has* to be 100% reliable or users' machines crash.
>>
>>> But if redoing mailbox overall saves you complexity, I am ok with it.
>>
>> Is that an ack? :-)
>>
> You sound like being trapped in a bad marriage with mailbox :) And
> I really don't want you to stay in a rewardless situation --- I have
> actually asked some platforms during RFCs if mailbox is really useful
> for them (usually SMC/HVC based useage), but they found use.
> Please make sure it is not just code-rage of your patchset being
> rejected, and indeed there are things you can't do with the api.
It isn't. There's no code rage here, that patch was a long time ago.
What that patch told me was that cleaning up mailbox to work for us was
going to be an uphill battle, and then over the course of the year+
after that it has become very evident that there is a lot of work to do
to make mailbox work for us. Hence, the conclusion that we're better off
without. Honestly, at this point, even without that rejection I'd still
want to move away because there's just so much work to do to get all the
features we need and bugs we're hitting fixed and no realistic way to
test other consumers/drivers to make sure we don't break them in the
process.
> Because the api can not have Zero impact on any platform's
> implementation and my ack here could be used as a precedent for every
> platform to implement their own tx/rx queues and dt handling and move
> into drivers/soc/.
As I said, there's a very clear sign here that this is the right move:
the overall code size goes down. After this series we have:
- Less code in total (much less actually executing)
- That works better
- And is easier to understand and debug
- And requires less maintenance effort to improve
If other platforms come to the same conclusion for their use case then
yes, they should move away from mailbox as well. I would expect that
might be the case for a subset, not all, of users. If more users follow,
that should be a sign to you that the mailbox subsystem isn't as useful
as you'd like :)
Put another way: common code should actually save you lines of code. If
it's causing you to spend more lines of code to use it properly than it
saves, it is not useful and does not actually improve the situation.
> A couple years later someone will see it doesn't> make sense every> platform is doing the same thing in driver/soc/ and
> maybe it s a good idea to have some drivers/mailbox/ to hold the
> common code.
If they are really doing the same thing, sure. And then might be a good
time to re-think mailbox and what it should do and how it should offer
this common code to drivers, in a way that works for more users and
actually saves everyone time and maintenance effort, with less burden.
> I am also aware I am just a volunteer at mailbox and can not dictate
> what you do with your platform. So, is there anything like
> Neither-acked-nor-objected-but-left-to-soc-by ? ;)
Not really, because it's your subsystem so we do actually need you to
ack the driver deletion patch if it's going to go through our tree.
That's the rules. "Acked" doesn't mean "I am happy with this", it means
"I am okay with this" ;)
- Hector
On Tue, Mar 28, 2023 at 9:14 AM Hector Martin <[email protected]> wrote:
>
> Once upon a time, Apple machines had some mailbox hardware, and we had
> to write a driver for it. And since it was a mailbox, it felt natural to
> use the Linux mailbox subsystem.
>
> More than a year later, it has become evident that was not the right
> decision.
>
> Linux driver class subsystems generally exist for a few purposes:
> 1. To allow mixing and matching generic producers and consumers.
> 2. To implement common code that is likely to be shared across drivers,
> and do so correctly so correct code only has to be written once.
> 3. To force drivers into a "correct" design, such that driver authors
> avoid common pitfalls.
>
> The mailbox subsystem does not do any of the above for us:
> 1. Mailbox hardware is not generic; "mailbox" is a vague idea, not a
> standard for communication. Almost all mailbox consumers are tied to
> one or a few producers. There is practically no mixing and matching
> possible. We have one (1) consumer subsystem (RTKit) talking to one
> (1) mailbox driver (apple-mailbox). We might have a second consumer
> in the future (SEP), but there will still be no useful
> combinatronics with other drivers.
> 2. The mailbox subsystem implements a bunch of common code for queuing,
> but we don't need that because our hardware has hardware queues. It
> also implements a bunch of common code for supporting multiple
> channels, but we don't need that because our hardware only has one
> channel (it has "endpoints" but those are just tags that are part of
> the message). On top of this, the mailbox subsystem makes design
> decisions unsuitable for our use case. Its queuing implementation
> has a fixed queue size and fails sends when full instead of pushing
> back by blocking, which is completely unsuitable for high-traffic
> mailboxes with hard reliability requirements, such as ours. We've
> also run into multiple issues around using mailbox in an atomic
> context (required for SMC reboot/shutdown requests).
> 3. Mailbox doesn't really do much for us as far as driver design.
> If anything, it has been forcing us to add extra workarounds for the
> impedance mismatches between the subsystem core and the hardware.
> Other drivers already are inconsistent in how they use the mailbox
> core, because the documentation is unclear on various details.
>
> The interface for mailboxes is very simple - basically just a send() and
> a receive callback. This series quite literally just rips out the
> middleman, and connects both sides together directly. There just isn't
> anything useful the mailbox common code is doing for us - it's just a
> pile of complexity in the middle that adds bugs, impedance mismatches,
> overhead, and offers no extra features we can use.
>
> This series offers:
>
> - A modest reduction in overall code size (-27 net lines excluding #1).
> - Fixes a pile of bugs related to using the mailbox subsystem and its
> quirks and limitations (race conditions when messages are already in
> the queue on startup, atomic issues, the list goes on).
> - Adds runtime-PM support.
> - Adds support for the FIFOs in the mailbox hardware, improving
> performance.
> - Simplifies code by removing extraneous memory allocations (the
> mailbox subsystem requires consumers to pass pointers to messages,
> instead of inlining them, even though messages are usually only one or
> two registers in size) and the requisite cleanup/freeing in the
> completion path.
>
> In addition, it paves the way for future Apple-specific mailbox
> optimizations, such as adding the ability to de-duplicate message sends
> if the same message is already known to be in the FIFO (which can be
> done by keeping a rolling history of recently sent messages). This is
> useful for doorbell-style messages, which are redundant to send more
> than once if not yet processed.
>
> Apple Silicon platforms use these mailboxes pervasively, including as
> part of the GPU submission hot path. On top of that, bad interactions
> with firmware coprocessors can cause immediate lockups or crashes with
> no recovery possible but a reboot. Our requirements for reliability and
> performance are probably much higher than the average mailbox user, and
> we'd much rather not have a bunch of common code getting in the way of
> performance profiling and future optimization. It doesn't make much
> sense for the mailbox subsystem either, since solving these issues would
> require major refactoring that is unlikely to provide significant
> benefit to most other users.
>
> So let's just call usage of the mailbox subsystem a failed experiment,
> and move the driver into soc/apple, where we can control the API and can
> add whatever peculiarities we need for our mailboxes. Farewell, mailbox.
>
> There are no changes to the DT bindings. This driver has been shipping
> in Asahi stable kernel packages for a week, with no regressions
> reported by any users.
>
> As an additional non-kernel-related benefit, this introduces a direct
> module dependency between consumers and the mailbox producer. This, in
> turn, is in the critical path for the NVMe driver on these platforms.
> Prior to this series, we had to have custom initramfs hooks to add
> apple-mailbox to distro initramfses, and accidentally removing these
> hooks would result in a completely unbootable system (there is no way
> for standard initramfs machinery to detect soft consumer/producer
> relationships like this, they usually just go looking for block device
> modules and their direct dependencies). We still need the initramfs
> hooks for other things, but with this change, completely removing all
> Apple-related initramfs hooks will at least result in a *bootable*
> system so you can fix the problem. This has already bit several users,
> and it also means many more distros have a chance of working out of the
> box (enough to let you install extra stuff) on these platforms, instead
> of having a hard requirement that *every single distro* fix up their
> initramfs generation in order to even boot/install on these platforms at
> all.
>
> Jassi: Ideally I'd like to get an ack on this and merge it all through
> asahi-soc, so we don't have to play things patch-by-patch across
> multiple merge cycles to avoid potentially broken intermediate states.
>
> Signed-off-by: Hector Martin <[email protected]>
> ---
> Hector Martin (5):
> soc: apple: rtkit: Get rid of apple_rtkit_send_message_wait
> soc: apple: mailbox: Add ASC/M3 mailbox driver
> soc: apple: rtkit: Port to the internal mailbox driver
> mailbox: apple: Delete driver
> soc: apple: mailbox: Rename config symbol to APPLE_MAILBOX
>
> MAINTAINERS | 2 -
> drivers/mailbox/Kconfig | 12 -
> drivers/mailbox/Makefile | 2 -
> drivers/mailbox/apple-mailbox.c | 441 -------------------------------------
> drivers/soc/apple/Kconfig | 15 +-
> drivers/soc/apple/Makefile | 3 +
> drivers/soc/apple/mailbox.c | 434 ++++++++++++++++++++++++++++++++++++
> drivers/soc/apple/mailbox.h | 48 ++++
> drivers/soc/apple/rtkit-internal.h | 8 +-
> drivers/soc/apple/rtkit.c | 133 +++--------
> include/linux/apple-mailbox.h | 19 --
> include/linux/soc/apple/rtkit.h | 18 --
> 12 files changed, 529 insertions(+), 606 deletions(-)
> ---
> base-commit: bdfe6de2695c5bccc663a5a7d530f81925d8bc10
> change-id: 20230328-soc-mailbox-3cb6bb2b0b2d
>
> Best regards,
> --
> Hector Martin <[email protected]>
>
>
Series LGTM.
Acked-by: Neal Gompa <[email protected]>
--
真実はいつも一つ！/ Always, there's only one truth!
On 31/03/2023 13.14, Hector Martin wrote:
> On 31/03/2023 01.35, Jassi Brar wrote:
>> On Wed, Mar 29, 2023 at 5:53 PM Hector Martin <[email protected]> wrote:
>>> On 30/03/2023 01.04, Jassi Brar wrote:
>>
>>>>> On top of this, the mailbox subsystem makes design
>>>>> decisions unsuitable for our use case. Its queuing implementation
>>>>> has a fixed queue size and fails sends when full instead of pushing
>>>>> back by blocking, which is completely unsuitable for high-traffic
>>>>> mailboxes with hard reliability requirements, such as ours. We've
>>>>> also run into multiple issues around using mailbox in an atomic
>>>>> context (required for SMC reboot/shutdown requests).
>>>>>
>>>> I don't think you ever shared the issues you were struggling with.
>>>
>>> I did try to send a patch clarifying/cleaning up inconsistent usage of
>>> the atomic codepath in other drivers, and you rejected it. At that point
>>> I gave up in trying to contribute to cleaning up the existing mess,
>>> because you're clearly not interested.
>>>
>> You mean https://lore.kernel.org/lkml/[email protected]/
>> Now I see where this code-rage comes from.
>>
>> But let me clarify even more...
>> You do not kill some api just because you don't need that and/or you
>> think that is "stupid" because you can't see past your own use-case.
>
> It is general Linux kernel policy not to have internal APIs with zero
> users. The Rust folks get pushback all the time for upstreaming stuff
> piecewise even though in that case there are known, upcoming,
> in-the-pipeline users (we do that too with rtkit but we always have
> upcoming users downstream and we're small enough nobody notices and
> complains :P). Having dead APIs that nobody uses and nobody can point at
> an upcoming use case for is technical debt. That's why my first patch in
> this series cleans up one of those on our side.
>
>>> This issue is clearly known, and it doesn't take a lot of thinking to
>>> realize that *any* queue length limit coupled with hard-fails on message
>>> sends instead of pushback is just unsuitable for many use cases. Maybe
>>> all existing mailbox users have intrinsically synchronous use cases that
>>> keep the queue idle enough, or maybe they're just broken only in corner
>>> cases that haven't come back to the mailbox subsystem yet. Either way,
>>> as far as I'm concerned this is broken by design in the general case.
>>>
>> You may be surprised but I do understand hardcoding limits on buffer
>> size is taboo.... unless benefits outweigh fingerpointing :)
>
> Using a fixed size buffer is not the problem, having no blocking
> mechanism when it gets full is the problem.
>
>> 2) The api relies on last_tx_done() to make sure we submit data only
>> when we have an all-clear ...
>
> That's not the issue, the issue is putting stuff *into* the queue, not
> taking it *out* of the queue and sending it to the hardware.
>
>> which is a platform specific way to
>> ensure signal will physically reach the remote (whether data is
>> accepted or not is upto the upper layer protocol and that's why it is
>> recommended to pass pointer to data, rather than data as the signal).
>> The way api is recommended (not required) to be used, the limit on
>> TX_QUEUE_LEN(20), is not impactful beyond the fifo size of the
>> controller. Though I am open to idea of seeing if tx failure should be
>> considered a possiblity even after last_tx_done.
>
> If I do this:
>
> for (int i = 0; i < 30; i++) {
> mbox_send_message(...);
> }
>
> Then, unless the remote is fast enough to accept messages faster than
> the CPU can send them, some of those sends will fail and refuse to send
> data, once the subsystem side queue is full.
>
> That is broken because it either loses data or forces the user to
> implement retry poll loops, neither of which is appropriate. The mailbox
> subsystem knows when the hardware can send data, it can properly block
> the send on that signal (which is exactly what my refactor in this
> series does when the hardware queue gets full).
>
> If we instead wait for the tx completion stuff before sending, then that
> defeats the point of having a queue because you'd be waiting for each
> prior message before sending a new one. And then you need to keep track
> of the last completion. And it requires a global serialization on the
> client side anyway unless you can guarantee you have less than
> QUEUE_SIZE clients. And you still have the issue of having to keep the
> message data around until that completion fires, which is more code and
> allocator overhead over just passing it inline, since it's a tiny amount
> of data. Etc etc etc.
>
> It is a bad API, using it properly and reliably requires basically
> re-implementing part of the subsystem logic in the consumer to work
> around the issues.
>
>> Iirc on lkml, people have reported using 1000s tx calls per second
>> within this queue limit. I don't know how you tried to interpret that
>> limit but would have helped to know your issue.
>
> For reference: Our GPU benchmarks will easily hit 18000+ TX calls per
> second through mailbox, even more for some corner cases (this is why I
> want to implement coalescing when the HW queue already has identical
> doorbells, to reduce that). More importantly, although the GPU side
> firmware is usually fast at processing this (it has an IRQ handler and
> its own doorbell coalescing), when GPU faults or errors happen it has
> latency spikes, and then we *must* block mailbox sends until it is ready
> to handle messages again. Dropping messages on the floor is not an
> option. This *has* to be 100% reliable or users' machines crash.
>
>>>
>>>> But if redoing mailbox overall saves you complexity, I am ok with it.
>>>
>>> Is that an ack? :-)
>>>
>> You sound like being trapped in a bad marriage with mailbox :) And
>> I really don't want you to stay in a rewardless situation --- I have
>> actually asked some platforms during RFCs if mailbox is really useful
>> for them (usually SMC/HVC based useage), but they found use.
>
>> Please make sure it is not just code-rage of your patchset being
>> rejected, and indeed there are things you can't do with the api.
>
> It isn't. There's no code rage here, that patch was a long time ago.
> What that patch told me was that cleaning up mailbox to work for us was
> going to be an uphill battle, and then over the course of the year+
> after that it has become very evident that there is a lot of work to do
> to make mailbox work for us. Hence, the conclusion that we're better off
> without. Honestly, at this point, even without that rejection I'd still
> want to move away because there's just so much work to do to get all the
> features we need and bugs we're hitting fixed and no realistic way to
> test other consumers/drivers to make sure we don't break them in the
> process.
>
>> Because the api can not have Zero impact on any platform's
>> implementation and my ack here could be used as a precedent for every
>> platform to implement their own tx/rx queues and dt handling and move
>> into drivers/soc/.
>
> As I said, there's a very clear sign here that this is the right move:
> the overall code size goes down. After this series we have:
>
> - Less code in total (much less actually executing)
> - That works better
> - And is easier to understand and debug
> - And requires less maintenance effort to improve
>
> If other platforms come to the same conclusion for their use case then
> yes, they should move away from mailbox as well. I would expect that
> might be the case for a subset, not all, of users. If more users follow,
> that should be a sign to you that the mailbox subsystem isn't as useful
> as you'd like :)
>
> Put another way: common code should actually save you lines of code. If
> it's causing you to spend more lines of code to use it properly than it
> saves, it is not useful and does not actually improve the situation.
>
>> A couple years later someone will see it doesn't> make sense every> platform is doing the same thing in driver/soc/ and
>> maybe it s a good idea to have some drivers/mailbox/ to hold the
>> common code.
>
> If they are really doing the same thing, sure. And then might be a good
> time to re-think mailbox and what it should do and how it should offer
> this common code to drivers, in a way that works for more users and
> actually saves everyone time and maintenance effort, with less burden.
>
>> I am also aware I am just a volunteer at mailbox and can not dictate
>> what you do with your platform. So, is there anything like
>> Neither-acked-nor-objected-but-left-to-soc-by ? ;)
>
> Not really, because it's your subsystem so we do actually need you to
> ack the driver deletion patch if it's going to go through our tree.
> That's the rules. "Acked" doesn't mean "I am happy with this", it means
> "I am okay with this" ;)
Ping? :-)
- Hector