From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DABE5C433EF for ; Sat, 22 Jan 2022 17:41:07 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 92CF781426; Sat, 22 Jan 2022 18:41:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 2EEDC8197D; Sat, 22 Jan 2022 18:41:04 +0100 (CET) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 50CED80FAE for ; Sat, 22 Jan 2022 18:41:01 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id 24ce7ec2; Sat, 22 Jan 2022 18:41:00 +0100 (CET) Date: Sat, 22 Jan 2022 18:41:00 +0100 (CET) From: Mark Kettenis To: Simon Glass Cc: kettenis@openbsd.org, u-boot@lists.denx.de, jh80.chung@samsung.com, trini@konsulko.com, sven@svenpeter.dev, marcan@marcan.st, bmeng.cn@gmail.com In-Reply-To: (message from Simon Glass on Sat, 22 Jan 2022 10:17:08 -0700) Subject: Re: [PATCH 7/8] nvme: apple: Add driver for Apple NVMe storage controller References: <20220114110438.58452-1-kettenis@openbsd.org> <20220114110438.58452-8-kettenis@openbsd.org> Message-ID: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean > From: Simon Glass > Date: Sat, 22 Jan 2022 10:17:08 -0700 > > Hi Mark, > > On Sat, 22 Jan 2022 at 07:45, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Fri, 21 Jan 2022 18:40:24 -0700 > > > > > > Hi Mark, > > > > > > On Fri, 14 Jan 2022 at 04:05, Mark Kettenis wrote: > > > > > > > > Add a driver for the NVMe storage controller integrated on > > > > Apple SoCs. This NVMe controller isn't PCI based and deviates > > > > from the NVMe standard in its implementation of the command > > > > submission queue and the integration of an NVMMU that needs > > > > to be managed. This commit tweaks the core NVMe code to > > > > support the linear command submission queue implemented by > > > > this controller. But setting up the submission queue and > > > > managing the NVMMU controller is handled by implementing > > > > the driver ops that were added in an earlier commit. > > > > > > > > Signed-off-by: Mark Kettenis > > > > Tested-on: firefly-rk3399 > > > > Tested-by: Mark Kettenis > > > > --- > > > > configs/apple_m1_defconfig | 1 + > > > > drivers/nvme/Kconfig | 11 ++ > > > > drivers/nvme/Makefile | 1 + > > > > drivers/nvme/nvme_apple.c | 233 +++++++++++++++++++++++++++++++++++++ > > > > 4 files changed, 246 insertions(+) > > > > create mode 100644 drivers/nvme/nvme_apple.c > > > > > > Tested on: Macbook Air M1 > > > Tested-by: Simon Glass > > > > > > > > > > > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig > > > > index cb235e4e7d..1528217b17 100644 > > > > --- a/configs/apple_m1_defconfig > > > > +++ b/configs/apple_m1_defconfig > > > > @@ -11,6 +11,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y > > > > # CONFIG_NET is not set > > > > # CONFIG_MMC is not set > > > > CONFIG_DEBUG_UART_ANNOUNCE=y > > > > +CONFIG_NVME_APPLE=y > > > > CONFIG_USB_XHCI_HCD=y > > > > CONFIG_USB_XHCI_DWC3=y > > > > CONFIG_USB_KEYBOARD=y > > > > diff --git a/drivers/nvme/Kconfig b/drivers/nvme/Kconfig > > > > index 78da444c8b..0cb465160b 100644 > > > > --- a/drivers/nvme/Kconfig > > > > +++ b/drivers/nvme/Kconfig > > > > @@ -10,6 +10,17 @@ config NVME > > > > This option enables support for NVM Express devices. > > > > It supports basic functions of NVMe (read/write). > > > > > > > > +config NVME_APPLE > > > > + bool "Apple NVMe controller support" > > > > + select NVME > > > > + help > > > > + This option enables support for the NVMe storage > > > > + controller integrated on Apple SoCs. This controller > > > > + isn't PCI-based based and deviates from the NVMe > > > > + standard implementation in its implementation of > > > > + the command submission queue and the integration > > > > + of an NVMMU that needs to be managed. > > > > + > > > > config NVME_PCI > > > > bool "NVM Express PCI device support" > > > > depends on PCI > > > > diff --git a/drivers/nvme/Makefile b/drivers/nvme/Makefile > > > > index fad9724e17..fa7b619446 100644 > > > > --- a/drivers/nvme/Makefile > > > > +++ b/drivers/nvme/Makefile > > > > @@ -3,4 +3,5 @@ > > > > # Copyright (C) 2017, Bin Meng > > > > > > > > obj-y += nvme-uclass.o nvme.o nvme_show.o > > > > +obj-$(CONFIG_NVME_APPLE) += nvme_apple.o > > > > obj-$(CONFIG_NVME_PCI) += nvme_pci.o > > > > diff --git a/drivers/nvme/nvme_apple.c b/drivers/nvme/nvme_apple.c > > > > new file mode 100644 > > > > index 0000000000..b0dc8492f0 > > > > --- /dev/null > > > > +++ b/drivers/nvme/nvme_apple.c > > > > @@ -0,0 +1,233 @@ > > > > +// SPDX-License-Identifier: GPL-2.0+ > > > > +/* > > > > + * (C) Copyright 2021 Mark Kettenis > > > > + */ > > > > + > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include "nvme.h" > > > > +#include > > > > + > > > > +#include > > > > +#include > > > > > > asm/arch/ should work > > > > It doesn't. For some reason I end up with > > > > arch/arm/include/asm/arch -> arch-m1 > > > > But this rtkit stuff is expected to be generic and apply to all Apple > > SoCs, not just the M1. > > Hmm so you plan to have an arch/m2 as well? Can we not put everything > in arch/apple then? We don't normally have arch directories for > different generations unless they are completely different. No, I think a single arch/arch-apple is better. That isolates us from whatever silly marketing names Apple comes up with for their SoCs. The goal is to have a single U-Boot binary that supports multiple generations of the SoC. That means I have to set SYS_SOC to "apple" instead of "m1" and move the existing uart.h file into arch/arm/include/arch/arch-apple/ isn't it? I can add a diff that does this to the series.