lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <050161aa-a257-9bf8-b3c9-35b13925b556@ti.com>
Date:   Tue, 23 Oct 2018 13:47:56 +0530
From:   Lokesh Vutla <lokeshvutla@...com>
To:     Santosh Shilimkar <santosh.shilimkar@...cle.com>,
        Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>,
        <tglx@...utronix.de>, <jason@...edaemon.net>,
        <marc.zyngier@....com>
CC:     Santosh Shilimkar <ssantosh@...nel.org>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, Tero Kristo <t-kristo@...com>,
        Sekhar Nori <nsekhar@...com>,
        Device Tree Mailing List <devicetree@...r.kernel.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Peter Ujfalusi <peter.ujfalusi@...com>
Subject: Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers

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.

Thanks and regards
Lokesh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ