Received: by 10.213.65.68 with SMTP id h4csp4023316imn; Tue, 10 Apr 2018 08:07:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx49ElIpIWxQNFrQ7kjvtZgaYZNPHqCqmwKhS2LkwBq02KW7P5C6UZaYw7GnrXp6ohRifE9UJ X-Received: by 10.98.238.4 with SMTP id e4mr703530pfi.212.1523372855721; Tue, 10 Apr 2018 08:07:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523372855; cv=none; d=google.com; s=arc-20160816; b=ibIuP4WJjeRl+HVFJbD1665emYQAEgJoY+LyQC3JViQ5wGGJ4WMkqaB1uLCLiiTFy2 ZZEhDWKYWY52jtCvofRtjLUTB5y6qwpNxCA0bIakOgY015uxgfO5Oea4NXH/6Opjxlhj ywRDCR8m/7Lm/ftO3nPysL2pRq1MrfJDQRezMfpjv9DjqB3MoWAEUnsbEWrn82tbY2no MJJKyvemqm1CG3rMiJthrfcoVoljn+rRsFKeWTgpL+4fao7dTo2SdBbZnyvEO+HCZAOj 7f65wSEW7TmH4GZmGzh+U07hE283Gh1hy29vCUNWMTK4tHN+Y1djpraTOG32ba9rRQ0d 6QPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=jSc6Xq9uFH0ojMuEZq7ImsYqTYig1RqO3rafiS4Wv18=; b=RtmgEkDtanjIcQidkR78ySH69K/v7vEsHNl6SvCzJyggg0XxRAuVaTXKw+xQagDOAT FEna7LAUp0g/jXGBWRjIfOCBuDCMKurw5wmpofCf7+aZSDp1voPo5KHtRolrc9XlPtjx AR4paddSDWIcpVZbolmw58XFj0lZ7q3H49dimALunjgUOf5JR0XIdFtgU22zN6Cr/idN +2uS8ouqmWjo72luWCvBGnT4ckyKA5hA9+N1BBDfK466m9rLwYYJBKHGTnvStcD/Rf7X 29fw8X12lAaAM+8ueFt2f6ZaMLvCPGakZ7ezOrPGcUUvTMgXQiNnnglaOvHHXJ+6+0Rl sekQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b72si2295557pfk.135.2018.04.10.08.06.58; Tue, 10 Apr 2018 08:07:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754364AbeDJPCJ (ORCPT + 99 others); Tue, 10 Apr 2018 11:02:09 -0400 Received: from mail.bootlin.com ([62.4.15.54]:52207 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754349AbeDJPCH (ORCPT ); Tue, 10 Apr 2018 11:02:07 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id CD40320867; Tue, 10 Apr 2018 17:02:05 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from windsurf (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 785B12072B; Tue, 10 Apr 2018 17:01:55 +0200 (CEST) Date: Tue, 10 Apr 2018 17:01:55 +0200 From: Thomas Petazzoni To: Marc Zyngier Cc: Stephen Boyd , Thomas Gleixner , Jason Cooper , linux-arm-msm@vger.kernel.org, Srinivas Kandagatla , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Hanna Hawa , =?UTF-8?B?TWlxdcOobA==?= Raynal Subject: Re: [PATCH] irqchip/gic-v3: Support v2m frame backwards compatibility mode Message-ID: <20180410170155.6e07113d@windsurf> In-Reply-To: References: <20170320223614.1351-1-sboyd@codeaurora.org> Organization: Bootlin (formerly Free Electrons) X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Marc, Hello Stephen, On Tue, 21 Mar 2017 09:43:24 +0000, Marc Zyngier wrote: > The whole idea behind this GICD_SETSPI_NSR is to offer a way to signal > SPIs using memory transaction, even allowing level interrupts (in > combinaison with the GICD_CLRSPI_NSR at offset 0x48). This is *not* a > GICv2m at all - only the offset is the same. > > The reasoning is that firmware would program the various devices with > the GICD_{CLR,SET}SPI_NSR addresses and the payload, and simply describe > this as an SPI in the device tree. Another reason for doing so is that > while we can always twist the DT to express anything, this cannot be > described in ACPI at all. > > Also, as you noticed, there is no provision in the architecture to > describe the range of message-based SPIs, because any SPI can be > signalled through that mechanism. It makes it impossible to distinguish > SPIs that are statically allocated (because it is a real wire) from > those that can be dynamically allocated (because it is just a number). > > You end-up having to describe the range of SPIs that can be generated > through messages at least on a per SoC basis, and maybe on a per board > basis. Not to mention that you're still only describing half of the > capability of the HW (what about level interrupts?). > > If we really want to support this kind of thing, I'd like to see level > interrupts supported as a first class citizen in our generic MSI > infrastructure, and then the GICv3 message-based SPIs as an client of > that infrastructure. We are trying to support a platform that has a GICv3, and that also uses level-triggered interrupts through GICD_SETSPI_NSR and GICD_CLRSPI_NSR. Therefore, I'm also interested in seeing this functionality of the GICv3 exposed as an MSI controller. In the current Marvell Armada 7K/8K, we have a unit called the ICU that turns wired level interrupts on one side of the chip into MSIs, signaled to the GIC through a special unit called GICP, which allowed to trigger SPIs in the GIC-400 by doing memory writes. See irq-mvebu-icu.c and irq-mvebu-gicp.c for the two sides of the story (MSI consumer and MSI provider). We have one hack between those two drivers: because those interrupts are level-triggered, we need the addresses of two registers, while 'struct msi_msg' only allows to pass one address, assuming MSIs are edge-triggered. In the upcoming Armada 8KP, we have a GICv3, which has built-in support for memory-triggered SPIs, thanks to the GICD_SETSPI_NSR and GICD_CLRSPI_NSR, and the ICU will directly use this GICv3 functionality. We would therefore very much like to have this GICv3 feature provided as a MSI controller, which as Marc said would require supporting level-triggered MSIs. Marc, let me know how we can collaborate on this topic. I'm able to either test some preliminary patches, or work on such patches if necessary (preferably with some initial directions). Thanks! Thomas -- Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com