| Message ID | 20220426201539.12829-1-sven@svenpeter.dev (mailing list archive) |
|---|---|
| Headers | show |
| Series | Apple M1 (Pro/Max) NVMe driver | expand |
On Tue, Apr 26, 2022 at 10:15 PM Sven Peter <sven@svenpeter.dev> wrote: > > Hi, > > This series includes everything[*] required to get NVMe up and running on > Apple's M1, M1 Pro and M1 Max SoCs. > > v1: https://lore.kernel.org/linux-nvme/20220321165049.35985-1-sven@svenpeter.dev/T/ > v2: https://lore.kernel.org/linux-nvme/20220415142055.30873-1-sven@svenpeter.dev/T/ > > Thanks everyone for the reviews of v2 again! There are just some minor > changes since v2 listed in the individual commits again. Nice! I had not looked at v2 in much detail, but I'm perfectly happy with this version, I found a few things that could be improved if you do a respin, but nothing important. > [*] The only missing part in this series are the device tree updates > but since these will go through arm-soc anyway I haven't included > them here but will instead submit them once this series is in a shape > where it can be merged. Just as a clarification: the drivers/soc/ portion should normally go through the soc tree as well, but I'm happy for those to get merged along with the nvme driver if that helps get it all mainlined more quickly. Arnd
On Tue, Apr 26, 2022, at 23:15, Arnd Bergmann wrote: > On Tue, Apr 26, 2022 at 10:15 PM Sven Peter <sven@svenpeter.dev> wrote: >> >> Hi, >> >> This series includes everything[*] required to get NVMe up and running on >> Apple's M1, M1 Pro and M1 Max SoCs. >> >> v1: https://lore.kernel.org/linux-nvme/20220321165049.35985-1-sven@svenpeter.dev/T/ >> v2: https://lore.kernel.org/linux-nvme/20220415142055.30873-1-sven@svenpeter.dev/T/ >> >> Thanks everyone for the reviews of v2 again! There are just some minor >> changes since v2 listed in the individual commits again. > > Nice! I had not looked at v2 in much detail, but I'm perfectly happy > with this version, > > I found a few things that could be improved if you do a respin, but > nothing important. Thanks, I'll respin it later this week to fix those things! > >> [*] The only missing part in this series are the device tree updates >> but since these will go through arm-soc anyway I haven't included >> them here but will instead submit them once this series is in a shape >> where it can be merged. > > Just as a clarification: the drivers/soc/ portion should normally go through the > soc tree as well, but I'm happy for those to get merged along with the > nvme driver > if that helps get it all mainlined more quickly. Makes sense! I don't think I'll be ready to submit USB3/USB4/Thunderbolt (which also needs RTKit) during this cycle but I think there's a decent chance marcan will submit SMC which also depends on RTKit and will go through a different subsystem. What's the best way to handle the RTKit commits in that case? It would be great if we could get both into 5.19. Sven
On Wed, Apr 27, 2022 at 5:33 PM Sven Peter <sven@svenpeter.dev> wrote: > On Tue, Apr 26, 2022, at 23:15, Arnd Bergmann wrote: > > On Tue, Apr 26, 2022 at 10:15 PM Sven Peter <sven@svenpeter.dev> wrote: > > Makes sense! > I don't think I'll be ready to submit USB3/USB4/Thunderbolt (which also needs > RTKit) during this cycle but I think there's a decent chance marcan will submit > SMC which also depends on RTKit and will go through a different subsystem. > What's the best way to handle the RTKit commits in that case? > It would be great if we could get both into 5.19. The usual trick is to have a branch with the shared patches and have that pulled into every other tree that needs these, but make sure you never rebase. In this case, you could have something like a) rtkit driver in a shared branch (private only) b) thunderbolt driver based on branch a), merged through thunderbolt/usb/pci tree (I don't know who is responsible here) c) sart driver based on branch a), merged through soc tree d) nvme driver based on branch c), merged through nvme tree since the commit hashes are all identical, each patch only shows up in the git tree once, but you get a somewhat funny history. Arnd
On Wed, Apr 27, 2022 at 07:39:49PM +0200, Arnd Bergmann wrote: > The usual trick is to have a branch with the shared patches and have > that pulled into every other tree that needs these, but make sure you never > rebase. In this case, you could have something like > > a) rtkit driver in a shared branch (private only) > b) thunderbolt driver based on branch a), merged through > thunderbolt/usb/pci tree (I don't know who is responsible here) > c) sart driver based on branch a), merged through soc tree > d) nvme driver based on branch c), merged through nvme tree > > since the commit hashes are all identical, each patch only shows up in > the git tree once, but you get a somewhat funny history. Given that the nvme driver is just addition of new code I'm perfectly fine with sending it through whatever tree is most convenient.
On Thu, Apr 28, 2022, at 16:24, hch@lst.de wrote: > On Wed, Apr 27, 2022 at 07:39:49PM +0200, Arnd Bergmann wrote: >> The usual trick is to have a branch with the shared patches and have >> that pulled into every other tree that needs these, but make sure you never >> rebase. In this case, you could have something like >> >> a) rtkit driver in a shared branch (private only) >> b) thunderbolt driver based on branch a), merged through >> thunderbolt/usb/pci tree (I don't know who is responsible here) >> c) sart driver based on branch a), merged through soc tree >> d) nvme driver based on branch c), merged through nvme tree >> >> since the commit hashes are all identical, each patch only shows up in >> the git tree once, but you get a somewhat funny history. > > Given that the nvme driver is just addition of new code I'm perfectly > fine with sending it through whatever tree is most convenient. So If I understand all this correctly either 1) I send a pull request with rtkit+sart to Arnd/soc@ followed by a pull request with the same commits + the nvme driver to Christoph/nvme to make sure the commit hashes in both trees are the same. or 2) I send a pull request with rtkit+sart+nvme to soc@ and we take the entire driver through there with Christoph's ack if Arnd is fine with carrying it as well. In either case SMC (or thunderbolt if I finish in time) can also be based on the same rtkit commit and could go into 5.19 as well. I don't have any preference here (not that my opinion matters much for this decision anyway :-)) Sven
On Fri, Apr 29, 2022 at 6:37 PM Sven Peter <sven@svenpeter.dev> wrote: > On Thu, Apr 28, 2022, at 16:24, hch@lst.de wrote: > > On Wed, Apr 27, 2022 at 07:39:49PM +0200, Arnd Bergmann wrote: > >> The usual trick is to have a branch with the shared patches and have > >> that pulled into every other tree that needs these, but make sure you never > >> rebase. In this case, you could have something like > >> > >> a) rtkit driver in a shared branch (private only) > >> b) thunderbolt driver based on branch a), merged through > >> thunderbolt/usb/pci tree (I don't know who is responsible here) > >> c) sart driver based on branch a), merged through soc tree > >> d) nvme driver based on branch c), merged through nvme tree > >> > >> since the commit hashes are all identical, each patch only shows up in > >> the git tree once, but you get a somewhat funny history. > > > > Given that the nvme driver is just addition of new code I'm perfectly > > fine with sending it through whatever tree is most convenient. > > So If I understand all this correctly either > 1) I send a pull request with rtkit+sart to Arnd/soc@ followed by > a pull request with the same commits + the nvme driver to > Christoph/nvme to make sure the commit hashes in both trees > are the same. > or > 2) I send a pull request with rtkit+sart+nvme to soc@ and we > take the entire driver through there with Christoph's ack > if Arnd is fine with carrying it as well. > > In either case SMC (or thunderbolt if I finish in time) can also be based > on the same rtkit commit and could go into 5.19 as well. > I don't have any preference here (not that my opinion matters much > for this decision anyway :-)) Correct, those are both ok. Arnd
Hi, This series includes everything[*] required to get NVMe up and running on Apple's M1, M1 Pro and M1 Max SoCs. v1: https://lore.kernel.org/linux-nvme/20220321165049.35985-1-sven@svenpeter.dev/T/ v2: https://lore.kernel.org/linux-nvme/20220415142055.30873-1-sven@svenpeter.dev/T/ Thanks everyone for the reviews of v2 again! There are just some minor changes since v2 listed in the individual commits again. Thanks, Sven [*] The only missing part in this series are the device tree updates but since these will go through arm-soc anyway I haven't included them here but will instead submit them once this series is in a shape where it can be merged. Sven Peter (6): dt-bindings: iommu: Add Apple SART DMA address filter dt-bindings: nvme: Add Apple ANS NVMe soc: apple: Always include Makefile soc: apple: Add SART driver soc: apple: Add RTKit IPC library nvme-apple: Add initial Apple SoC NVMe driver .../devicetree/bindings/iommu/apple,sart.yaml | 52 + .../bindings/nvme/apple,nvme-ans.yaml | 111 ++ MAINTAINERS | 4 + drivers/nvme/host/Kconfig | 13 + drivers/nvme/host/Makefile | 3 + drivers/nvme/host/apple.c | 1598 +++++++++++++++++ drivers/soc/Makefile | 2 +- drivers/soc/apple/Kconfig | 24 + drivers/soc/apple/Makefile | 6 + drivers/soc/apple/rtkit-crashlog.c | 154 ++ drivers/soc/apple/rtkit-internal.h | 62 + drivers/soc/apple/rtkit.c | 958 ++++++++++ drivers/soc/apple/sart.c | 328 ++++ include/linux/soc/apple/rtkit.h | 159 ++ include/linux/soc/apple/sart.h | 57 + 15 files changed, 3530 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/iommu/apple,sart.yaml create mode 100644 Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml create mode 100644 drivers/nvme/host/apple.c create mode 100644 drivers/soc/apple/rtkit-crashlog.c create mode 100644 drivers/soc/apple/rtkit-internal.h create mode 100644 drivers/soc/apple/rtkit.c create mode 100644 drivers/soc/apple/sart.c create mode 100644 include/linux/soc/apple/rtkit.h create mode 100644 include/linux/soc/apple/sart.h