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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 E0166C46475 for ; Tue, 23 Oct 2018 08:27:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A342F20652 for ; Tue, 23 Oct 2018 08:27:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A342F20652 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727803AbeJWQtm (ORCPT ); Tue, 23 Oct 2018 12:49:42 -0400 Received: from foss.arm.com ([217.140.101.70]:54556 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727210AbeJWQtm (ORCPT ); Tue, 23 Oct 2018 12:49:42 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D540680D; Tue, 23 Oct 2018 01:27:21 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D17EE3F71D; Tue, 23 Oct 2018 01:27:13 -0700 (PDT) Date: Tue, 23 Oct 2018 09:27:07 +0100 Message-ID: <864lddt6ec.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Lokesh Vutla Cc: Santosh Shilimkar , Nishanth Menon , Rob Herring , , , Santosh Shilimkar , Linux ARM Mailing List , , Tero Kristo , Sekhar Nori , Device Tree Mailing List , Grygorii Strashko , Peter Ujfalusi Subject: Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers In-Reply-To: <050161aa-a257-9bf8-b3c9-35b13925b556@ti.com> References: <20181018154017.7112-1-lokeshvutla@ti.com> <942981b8-7536-2b6b-ad49-dc59671cbda6@oracle.com> <050161aa-a257-9bf8-b3c9-35b13925b556@ti.com> 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/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Oct 2018 09:17:56 +0100, Lokesh Vutla wrote: > > Hi Santosh, > > On Tuesday 23 October 2018 02:09 AM, Santosh Shilimkar wrote: > > On 10/18/2018 8:40 AM, Lokesh Vutla wrote: > >> TISCI abstracts the handling of IRQ routes where interrupt sources > >> are not directly connected to host interrupt controller. This series > >> adds support for: > >> - TISCI commands needed for IRQ configuration > >> - Interrupt Router(INTR) and Interrupt Aggregator(INTA) drivers > >> > >> More information on TISCI IRQ management can be found here[1]. > >> Complete TISCI resource management information can be found here[2]. > >> AM65x SoC related TISCI information can be found here[3]. > >> INTR and INTA related information can be found in TRM[4]. > >> > > I didn't read the specs but from what you described in > > INTA and INTR bindings, does the flow of IRQs like below ? > > > > Device IRQ(e.g USB) -->INTR-->INTA--->HOST IRQ controller(GIC) > > Not all devices in SoC are connected to INTA. Only the devices that > are capable of generating events are connected to INTA. And INTA is > connected to INTR. > > So there are three ways in which IRQ can flow in AM65x SoC: > 1) Device directly connected to GIC > - Device IRQ --> GIC > - (Most legacy peripherals like MMC, UART falls in this case) > 2) Device connected to INTR. > - Device IRQ --> INTR --> GIC > - This is cases where you want to mux IRQs. Used for GPIOs and Mailboxes > - (This is somewhat similar to crossbar on DRA7 devices) > 3) Devices connected to INTA. > - Device Event --> INTA --> INTR --> GIC > - Used for DMA and networking devices. > > Events are messages based on a hw protocol, sent by a master over a > dedicated Event transport lane. Events are highly precise that no > under/over flow of data transfer occurs at source/destination > regardless of distance and latency. So this is mostly preferred in DMA > and networking usecases. Now Interrupt Aggregator(IA) has the logic to > converts these events to Interrupts. Can we stop with these events already? What you describe here *is* an interrupt. The fact that you have some other dedicated infrastructure in your SoC is an implementation detail that doesn't concern the kernel at all. So this should be modelled as an interrupt, and not have its own special interface at all. Thanks, M. -- Jazz is not dead, it just smell funny.