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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDE54C2D0DB for ; Sat, 25 Jan 2020 12:02:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C21972075E for ; Sat, 25 Jan 2020 12:02:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579953762; bh=0A/Ixkpv30Yc0M9C6XxheVYT/svxocDivrkuGvIc7ag=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=q84utLKcNVA5LMtCuSxBCCGb2d4SwINOleWbHCJaGQlHnz10v1cJmB6TsHY83y3BM J5hf9Af1SnNO3aFEiX13B99oRa6BnOxrw2/KhE97cnNFnL3J0DEhx+G7a/6zETD3FH zDSBdpRMWyDb6aa6ZTquCVFMc/ENE8Lkajfpc9tc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729098AbgAYMCm (ORCPT ); Sat, 25 Jan 2020 07:02:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:37868 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726191AbgAYMCl (ORCPT ); Sat, 25 Jan 2020 07:02:41 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 90285206D3; Sat, 25 Jan 2020 12:02:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579953760; bh=0A/Ixkpv30Yc0M9C6XxheVYT/svxocDivrkuGvIc7ag=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=O41MDSX7vT1ogXxZh3nbnmV/K4XzYQ4jvMZkaxTgPzZYRoBS/mq1P61c6w8eIXKTf dA5tMBeL7f8JPt7D4nNzU2rOFr2JhrIeg4cAjB4Fs5MjcDqS4v7yz/IPDITp+ebAsG RwUQ2z/x1qjaPQhQXqv3epTRDxXxCwWJgYxp2H4I= Received: from [176.12.107.132] (helo=big-swifty.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ivK97-001NGG-Ss; Sat, 25 Jan 2020 12:02:38 +0000 Date: Sat, 25 Jan 2020 12:02:18 +0000 Message-ID: <86a76b7nhx.wl-maz@kernel.org> From: Marc Zyngier To: okitain@elvees.com Cc: Thomas Gleixner , Jason Cooper , linux-kernel@vger.kernel.org Subject: Re: irqchip: Figuring out utility of hierarchy irqdomain In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 176.12.107.132 X-SA-Exim-Rcpt-To: okitain@elvees.com, tglx@linutronix.de, jason@lakedaemon.net, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Jan 2020 15:50:55 +0000, Olga Kitaina wrote: Hi Olga, > > Hi, I'm looking to implement an interrupt controller (referred to here > as QLIC) that is based on the RISC-V PLIC (see > drivers/irqchip/irq-sifive-plic.c), with the difference that it's not > the root interrupt controller, but instead it is connected to a GIC. Mixing architectures, always a fun thing! WHat could possibly go wrong? ;-) > The features of the controller are as follows: > > * A cluster of DSPs serve as interrupt sources to QLIC, each DSP > with several interrupt lines going to QLIC. I don't think they are relevant to the problem. For the rest of the system, these DSPs are just another interrupt source. > * Several interrupt lines (documented as TARGET_x) go from QLIC to > * the GIC. I suppose each of these lines are what would normally connect to RISC-V CPUs, each line targeting a hart, right? > * Sources are mapped to targets by way of writing a mask of allowed > sources in the TARG_x_ENABLE register. OK, so that's both your internal routing and the enabling. I expect this to be fairly static. > * The source of an interrupt mapped to TARGET_x can be determined by > reading from register TARG_x_CC. Writing the number of the source to > TARG_x_CC masks the interrupt. This doesn't match my reading the PLIC driver. Writing back to the CONTEXT_CLAIM register *EOIs* the interrupt. It is *reading* from it that has the side effect of masking it, by virtue of being an Ack operation that progresses the interrupt state machine. Masking/unmasking the interrupt seems to be done by writing to an offset from CONTEXT_BASE, which is both per hart and per interrupt. > * To mask all interrupts corresponding to TARGET_x, TARG_x_CC must be > read repeatedly, with the values written back after the source > interrupt is handled. See above. You seem to have based your understanding of the PLIC on an older version of the driver (before it was fixed), instead of the documentation. This is of course assuming your QLIC is actually a PLIC. If not, please point me to some documentation. > * Source numbers start from 1, 0 is a special case in TARG_x_CC - it > corresponds to "no interrupt", and writing 0 to the register does > nothing. That's just a spurious interrupt, which can happen at any time. A number of interrupt architectures have similar concept (1023 on the ARM GIC). > I am not yet well-acquainted with the irq subsystem, which means I > am not sure what kind of APIs I need to use. This is why I have a > couple of questions: > 1. Do I understand correctly that using hierarchy irqdomain means that > the interrupt controller has to have a 1:1 mapping between inputs and > outputs? Yes. The typical use case is stacks of controllers that will never multiplex signals along the way. In your case, you have a bunch of interrupts that can be mux'ed onto a single output, so a hierarchical setup wouldn't work. > 2. Is a chained handler necessary for this setup, e.g. handling 0 in > TARG_x_CC? It is required (see above), but 0 isn't the reason why. Your QLIC, if it is anything like the PLIC, looks like *multiple* chained controllers, each one having a *single* output, each one connected to a GIC line. Hope this helps, M. -- Jazz is not dead, it just smells funny.