Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1907192pxm; Thu, 24 Feb 2022 11:46:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJyjZrRiLQlG13LV5d/25RcJI28+IR9zKsbGPlR1jR0Nos6u4/XWBoF75BRSwHj7NNTjm2xp X-Received: by 2002:a17:903:1c6:b0:14f:45c3:6c29 with SMTP id e6-20020a17090301c600b0014f45c36c29mr4076452plh.77.1645731966832; Thu, 24 Feb 2022 11:46:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645731966; cv=none; d=google.com; s=arc-20160816; b=uBCHNKP7pQalmPIenFen9pns5cB/aJ7Gpykl63/NBrhROslCQVXJb159ErCLOGrkvY K/cl2Ardqf6GxlKejAi2salZA+fkBXzcA6nRGc9won0NMwXJOetBc/Hep9qkRKjCfKAI kbVNCRqroCvkuqcAsAGv0/bwjdyOgEs9sLi/cYxmYSS3dhY4A87XXck47N13yxwLcEBL dJ09iC165MQ29XXsQp4uOVkCtN88Wcd97vdjcHkhoXEWnYykZxTU9vO/h3MEq2rNbpbk gtrgkoPNpxgHdUVTrYeFnmi6oJTWY1k7kn0WZ7+qyTcRSVrJrHAbMmWVC1F/F0SuC2pl TyCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=esLyuc3N+ocG1knDEpXNR7w33Yf9xmUYb89VNH//bFs=; b=V8iUmEOnyzgiuOjC/G8hWMmtKL64RfpjsMuQnvXPIro06Wp9nsDqsuvWu+XYOMaApa fV0k1wiVDHAQFSHlhT7c9zeYx+TTWMPreuumzer5PgVnafEgvJ5vm7liPV6Z8+1GtzB9 AjZ36+vHGyd/iEXg2UfKOy+YtpqVOB1DwYDopUK3li5iObT7uWRenq5meVwHJJjyc6ZD poVkb8xabv2hfkf21gvwRbclG1zcJe82WzHYXNiI53KQ4KZ3NP9zhZVfD9bIm8mRBeBI 5Zv+W1MANytJb39czQ8Bp/9v7UaqHcimL73JcSWGP1qKDnRqkkJ6AoD5acIB51S5ol7b QEsg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y5-20020a1709029b8500b0014f9a608b16si60309plp.537.2022.02.24.11.45.49; Thu, 24 Feb 2022 11:46:06 -0800 (PST) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232821AbiBXS1X (ORCPT + 99 others); Thu, 24 Feb 2022 13:27:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230443AbiBXS1W (ORCPT ); Thu, 24 Feb 2022 13:27:22 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C106B3A709; Thu, 24 Feb 2022 10:26:49 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D305B106F; Thu, 24 Feb 2022 10:26:48 -0800 (PST) Received: from lakrids (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8292B3F70D; Thu, 24 Feb 2022 10:26:47 -0800 (PST) Date: Thu, 24 Feb 2022 18:26:41 +0000 From: Mark Rutland To: Hector Martin Cc: Thomas Gleixner , Marc Zyngier , Rob Herring , Sven Peter , Alyssa Rosenzweig , Mark Kettenis , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v2 0/7] irqchip/apple-aic: Add support for AICv2 Message-ID: References: <20220224130741.63924-1-marcan@marcan.st> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220224130741.63924-1-marcan@marcan.st> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 On Thu, Feb 24, 2022 at 10:07:34PM +0900, Hector Martin wrote: > Hi folks, Hi Hector, > In the t6000/t6001 (M1 Pro / Max) SoCs, Apple introduced a new version > of their interrupt controller. This is a significant departure from > AICv1 and seems designed to better scale to larger chips. This series > adds support for it to the existing AIC driver. > > Gone are CPU affinities; instead there seems to be some kind of > "automagic" dispatch to willing CPU cores, and cores can also opt-out > via an IMP-DEF sysreg (!). Right now the bootloader just sets up all > cores to accept IRQs, and we ignore all this and let the magic > algorithm pick a CPU to accept the IRQ. Maybe that's ok for the set of peripherals attached, but in general that violates existing expectations regarding affinity, and I fear there'll be some subtle brokenness resulting from this automatic target selection. For example, in the perf events subsystem there are PMU drivers (even those for "uncore" or "system" devices which are shared by many/all CPUs) which rely on a combination of interrupt affinity and local IRQ masking (without any other locking) to provide exclusion between a PMU's IRQ handler and any other management operations for that PMU (which are all handled from the same CPU). > In the future, we might start making use of these finer-grained > capabilities for e.g. better real-time guarantees (CPUs running RT > threads might opt out of IRQs). What mechanism does the HW have for affinity selection? The wording above makes it sound like each CPU has to opt-out rather than having a central affinity selection. Is there a mechanism to select a single target? Thanks, Mark. > Legacy IPI support is also gone, so this implements Fast IPI support. > Fast IPIs are implemented entirely in the CPU core complexes, using > FIQs and IMP-DEF sysregs. This is also supported on t8103/M1, so we > enable it there too, but we keep the legacy AIC IPI codepath in case > it is useful for backporting to older chips. > > This also adds support for multi-die AIC2 controllers. While no > multi-die products exist yet, the AIC2 in t600x is built to support > up to 2 dies, and it's pretty clear how it works, so let's implement > it. If we're lucky, when multi-die products roll around, this will > let us support them with only DT changes. In order to support the > extra die dimension, this introduces a 4-argument IRQ phandle form > (3-argument is always supported and just implies die 0). > > All register offsets are computed based on capability register values, > which should allow forward-compatibility with future AIC2 variants... > except for one. For some inexplicable reason, the number of actually > implemented die register sets is nowhere to be found (t600x has 2, > but claims 1 die in use and 8 dies max, neither of which is what we > need), and this is necessary to compute the event register offset, > which is page-aligned after the die register sets. We have no choice > but to stick this offset in the device tree... which is the same thing > Apple do in their ADT. > > Changes since v1: > - Split off the DT binding > - Changed fast-ipi codepath selection to use a static key for performance > - Added fix for PCI driver to support the new 4-cell IRQ form > - Minor style / review feedback fixes > > Hector Martin (7): > PCI: apple: Change MSI handling to handle 4-cell AIC fwspec form > dt-bindings: interrupt-controller: apple,aic2: New binding for AICv2 > irqchip/apple-aic: Add Fast IPI support > irqchip/apple-aic: Switch to irq_domain_create_tree and sparse hwirqs > irqchip/apple-aic: Dynamically compute register offsets > irqchip/apple-aic: Support multiple dies > irqchip/apple-aic: Add support for AICv2 > > .../interrupt-controller/apple,aic2.yaml | 99 ++++ > MAINTAINERS | 2 +- > drivers/irqchip/irq-apple-aic.c | 432 +++++++++++++++--- > drivers/pci/controller/pcie-apple.c | 2 +- > 4 files changed, 458 insertions(+), 77 deletions(-) > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml > > -- > 2.33.0 >