Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
Hi Santosh, On Tuesday 23 October 2018 11:04 PM, Santosh Shilimkar wrote: On 10/23/2018 1:17 AM, 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. This helps but none of the kernel doc you added, makes this clear so perhaps you want to add this info to make that clear for reviewers as well as for future reference. Sure will add it. Now regarding the events, no matter how they are routed/processed within SOC, they are essentially interrupts so I do agree with Marc's other comment. Agreed. Marc suggested to use MSI in this scenario. Currently working in that direction. Will repost the series once it is done. Thanks and regards, Lokesh Thanks for explanation again !! regards, Santosh
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
Hi Santosh, On Tuesday 23 October 2018 11:04 PM, Santosh Shilimkar wrote: On 10/23/2018 1:17 AM, 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. This helps but none of the kernel doc you added, makes this clear so perhaps you want to add this info to make that clear for reviewers as well as for future reference. Sure will add it. Now regarding the events, no matter how they are routed/processed within SOC, they are essentially interrupts so I do agree with Marc's other comment. Agreed. Marc suggested to use MSI in this scenario. Currently working in that direction. Will repost the series once it is done. Thanks and regards, Lokesh Thanks for explanation again !! regards, Santosh
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
On 10/23/2018 1:17 AM, 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. This helps but none of the kernel doc you added, makes this clear so perhaps you want to add this info to make that clear for reviewers as well as for future reference. Now regarding the events, no matter how they are routed/processed within SOC, they are essentially interrupts so I do agree with Marc's other comment. Thanks for explanation again !! regards, Santosh
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
On 10/23/2018 1:17 AM, 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. This helps but none of the kernel doc you added, makes this clear so perhaps you want to add this info to make that clear for reviewers as well as for future reference. Now regarding the events, no matter how they are routed/processed within SOC, they are essentially interrupts so I do agree with Marc's other comment. Thanks for explanation again !! regards, Santosh
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
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.
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
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.
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
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
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
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) The confusing part is aggregator and can multiplex as well as grouping but seems like its event grouping or multiplexing than actual device IRQ grouping or multi-plexsing. What am I missing ? Regards,S antosh
Re: [PATCH v2 00/10] Add support for TISCI irqchip drivers
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) The confusing part is aggregator and can multiplex as well as grouping but seems like its event grouping or multiplexing than actual device IRQ grouping or multi-plexsing. What am I missing ? Regards,S antosh
[PATCH v2 00/10] Add support for TISCI irqchip drivers
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]. [1] http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html [2] http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/index.html#resource-management-rm [3] http://downloads.ti.com/tisci/esd/latest/5_soc_doc/index.html#am6-soc-family [4] http://www.ti.com/lit/pdf/spruid7 Changes since v1: - Consolidated both TISCI and irqchip drivers as suggested by Marc. - Each patch contains respective changes. Grygorii Strashko (1): firmware: ti_sci: Add support to get TISCI handle using of_phandle Lokesh Vutla (8): firmware: ti_sci: Add support for RM core ops firmware: ti_sci: Add support for IRQ management firmware: ti_sci: Add helper apis to manage resources dt-bindings: irqchip: Introduce TISCI Interrupt router bindings irqchip: ti-sci-intr: Add support for Interrupt Router driver dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver soc: ti: am6: Enable interrupt controller drivers Peter Ujfalusi (1): firmware: ti_sci: Add RM mapping table for am654 .../bindings/arm/keystone/ti,sci.txt | 3 +- .../interrupt-controller/ti,sci-inta.txt | 74 ++ .../interrupt-controller/ti,sci-intr.txt | 81 ++ MAINTAINERS | 4 + drivers/firmware/ti_sci.c | 850 ++ drivers/firmware/ti_sci.h | 102 +++ drivers/irqchip/Kconfig | 22 + drivers/irqchip/Makefile | 2 + drivers/irqchip/irq-ti-sci-inta.c | 613 + drivers/irqchip/irq-ti-sci-intr.c | 302 +++ drivers/soc/ti/Kconfig| 3 + include/linux/irqchip/irq-ti-sci-inta.h | 35 + include/linux/soc/ti/ti_sci_protocol.h| 169 13 files changed, 2259 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt create mode 100644 drivers/irqchip/irq-ti-sci-inta.c create mode 100644 drivers/irqchip/irq-ti-sci-intr.c create mode 100644 include/linux/irqchip/irq-ti-sci-inta.h -- 2.19.1
[PATCH v2 00/10] Add support for TISCI irqchip drivers
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]. [1] http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html [2] http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/index.html#resource-management-rm [3] http://downloads.ti.com/tisci/esd/latest/5_soc_doc/index.html#am6-soc-family [4] http://www.ti.com/lit/pdf/spruid7 Changes since v1: - Consolidated both TISCI and irqchip drivers as suggested by Marc. - Each patch contains respective changes. Grygorii Strashko (1): firmware: ti_sci: Add support to get TISCI handle using of_phandle Lokesh Vutla (8): firmware: ti_sci: Add support for RM core ops firmware: ti_sci: Add support for IRQ management firmware: ti_sci: Add helper apis to manage resources dt-bindings: irqchip: Introduce TISCI Interrupt router bindings irqchip: ti-sci-intr: Add support for Interrupt Router driver dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver soc: ti: am6: Enable interrupt controller drivers Peter Ujfalusi (1): firmware: ti_sci: Add RM mapping table for am654 .../bindings/arm/keystone/ti,sci.txt | 3 +- .../interrupt-controller/ti,sci-inta.txt | 74 ++ .../interrupt-controller/ti,sci-intr.txt | 81 ++ MAINTAINERS | 4 + drivers/firmware/ti_sci.c | 850 ++ drivers/firmware/ti_sci.h | 102 +++ drivers/irqchip/Kconfig | 22 + drivers/irqchip/Makefile | 2 + drivers/irqchip/irq-ti-sci-inta.c | 613 + drivers/irqchip/irq-ti-sci-intr.c | 302 +++ drivers/soc/ti/Kconfig| 3 + include/linux/irqchip/irq-ti-sci-inta.h | 35 + include/linux/soc/ti/ti_sci_protocol.h| 169 13 files changed, 2259 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt create mode 100644 drivers/irqchip/irq-ti-sci-inta.c create mode 100644 drivers/irqchip/irq-ti-sci-intr.c create mode 100644 include/linux/irqchip/irq-ti-sci-inta.h -- 2.19.1
