From patchwork Tue Mar 28 13:14:13 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hector Martin X-Patchwork-Id: 7339 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2217022vqo; Tue, 28 Mar 2023 06:28:56 -0700 (PDT) X-Google-Smtp-Source: AKy350abybLSOVjpZ5WYntK80cEud9nc5x2Qxx77VvOCNduCF5+n8/WnVX9Bp3vSRtg/zxTizkdY X-Received: by 2002:a17:906:9f18:b0:930:f953:962c with SMTP id fy24-20020a1709069f1800b00930f953962cmr15293496ejc.1.1680010135983; Tue, 28 Mar 2023 06:28:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680010135; cv=none; d=google.com; s=arc-20160816; b=Qhmu0i6mSBHrwtNGpeocq+pAPzLqKdpxTv97Uncajm1Eq1TWvwZsEe2P1tFw7dB0vu GpUbe+OY+0r5DIByN9bAVbn1E3wzKsiRR2mcN1R5/6dvkiLaY47N7Ss/HwKILx4Ym0af gb/NoINPtEaRKIUPk3Ct2DRlVICpGJpaZnWwZV0Virga+Iw9HZ0gYpZPW3kQq2+nJ+8K ebbmXM1jnlIk6KMhkTi1/OjXnMtMuWkKSmvsWxCpp0K9+t9tOQxviGRgNb3rPvCMqVoC e7z+mIo1mpVCxsRQxj7tIfKxcPI0pwhErcsOrasBSiSPlVHtVOp0qZ96cFqHeKOXWmCU RTnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from:dkim-signature; bh=JTLUQs6OTtitUf5veRWstYRdd1z6de/Iky8aGhSBUxY=; b=oBd2yftDFlr3WpJEk631a1D80gqToTQLmLTSQu0Y4tlYmnOO/2JJuI6YZWOB/q9WVE wYJg5GC789UNKlO8dqTCDMiATiDJJGTfAwfAfDPXOHfjbfswAFLYe2vAW7TLnT+99WT3 Sl1S9SHnlRGvXf2/eZMzYNbKrgrOjZRA8Pymz/04S5jUSUVi+PbQvaCz08Yoy5aS+jMa GR9TPuPuhxkWAv11SBxpvqIDLMuUBk4md6vXdgZxZR/SJqyAW8RyTcNv/Zppli+OprgC Lav6j6NaDkpBYm02aavOsoqAjGq5rUvEtECc017qyWnx1V+y3VaBfBi1MvlNvqvkVTP8 7TtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@marcan.st header.s=default header.b=xpUVdKC+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id vk6-20020a170907cbc600b00935ad387614si10006231ejc.376.2023.03.28.06.28.31; Tue, 28 Mar 2023 06:28:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@marcan.st header.s=default header.b=xpUVdKC+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232904AbjC1NPE (ORCPT + 99 others); Tue, 28 Mar 2023 09:15:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233151AbjC1NOt (ORCPT ); Tue, 28 Mar 2023 09:14:49 -0400 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4AE25BDC4 for ; Tue, 28 Mar 2023 06:14:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: sendonly@marcansoft.com) by mail.marcansoft.com (Postfix) with ESMTPSA id F37664249A; Tue, 28 Mar 2023 13:14:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=marcan.st; s=default; t=1680009279; bh=lxvhejkVmHIeLDKJ1WfCX9rAEaFaDuJoLlJU1yR9f0w=; h=From:Subject:Date:To:Cc; b=xpUVdKC+WeCg3hEZUjTOOJwtaHxzOGS9vGj7h+i6nvPpVD2PUnRQaRN1hgxMfyyDJ uYxiauOUnCME8FlYZPHVk/344VzPG046Mpgn81cwpTJIbgZD0PYq26RS97YUPQUcks lonyPQRovp+lix5lr0e4Jj2dPlvlM4UFcfE2CL6VRmRGEaMoXqNAdt8LwgLfxo/eHz eekLvNHI0ct9vfoz5G2mXZJjFCJ87MHMORLBRtihUPiksZLiHs5+9xAI9Sfc0pAXkG Wio5Ywft7ig3SvHVAKmhsiPzFoNGWUT3RXNTeEkg4zGL66SzDnCQi6NFnAeHLNhXTq hoUnu2amTjW/w== From: Hector Martin Subject: [PATCH 0/5] mailbox: apple: Move driver into soc/apple and stop using the subsystem Date: Tue, 28 Mar 2023 22:14:13 +0900 Message-Id: <20230328-soc-mailbox-v1-0-3953814532fd@marcan.st> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIACboImQC/x2NQQoCMQxFrzJkbbCmIOJVxEXSyUwD2koDMjDM3 W1d/MXj83g7uDZTh/u0Q9OvudXS4XKaIGUuq6LNnYECxRDphl4TvtleUjeMSa4iJEFohm4Iu6I 0LikPh52zDeHcN/5P08W2f+3xPI4fSozfB30AAAA= To: Sven Peter , Alyssa Rosenzweig , Jassi Brar , Janne Grunau Cc: linux-kernel@vger.kernel.org, asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Hector Martin X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=7458; i=marcan@marcan.st; h=from:subject:message-id; bh=lxvhejkVmHIeLDKJ1WfCX9rAEaFaDuJoLlJU1yR9f0w=; b=owGbwMvMwCEm+yP4NEe/cRLjabUkhhSlFxaSj12LYpZbs6rHV8V/zdlmFSP0mytsvfcVx9cde 3/dPJrRUcrCIMbBICumyNJ4ovdUt+f0c+qqKdNh5rAygQxh4OIUgIvcY/jDs/flm7MeP9f82hrL EfEj6Z/Ppax+Vke59St9H0/6u+jpCYb/FTynf6o8ecI8rzHtnvvy/6o/uK5EZIXtfPHdOVXc5Po +TgA= X-Developer-Key: i=marcan@marcan.st; a=openpgp; fpr=FC18F00317968B7BE86201CBE22A629A4C515DD5 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761618307997559103?= X-GMAIL-MSGID: =?utf-8?q?1761618307997559103?= 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 Acked-by: Neal Gompa --- 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,