On 12/10/2020 10.31, Marc Zyngier wrote: > On 2020-10-09 09:58, Peter Ujfalusi wrote: >> Marc, >> > > [...] > >> The design of irqchip/irq-ti-sci-inta.c, soc/ti/ti_sci_inta_msi.c and >> irqchip/irq-ti-sci-intr.c created to handle the interrupt needs present >> in K3 devices with NAVSS. >> DMSS of newer K3 devices extends and simplifies the NAVSS components and >> a big part of that change was done with the INTA and DMAs. >> System Firmware also changed to adopt to these changes. >> >> As an example, let's assume that we want an interrupt from a ring. >> The high level of the events in this case are: >> >> NAVSS: >> 1.1 ring generates an internal signal (up or down) >> 1.2 the ringacc will send a (mapped) Global Event to INTA >> 1.3 When INTA receives the global event, it will signal it's outgoing >> VINT to INTR >> 1.4 INTR will trigger a host interrupt. >> >> DMSS >> 1.1 ring generates an internal signal (up or down) >> 1.2 the DMA (ring is now part of the DMA) will send an unmapped event to >> INTA >> 1.3 When INTA receives the unmapped event, it will send a (mapped) >> Global Event to itself >> 1.4 When INTA receives the global event, it will signal it's outgoing >> VINT to INTR >> 1.5 INTR will trigger a host interrupt. >> >> The API from sysfw is the same to configure the global events and VINT, >> but we need to use the INTA's tisci device identification number to let >> sysfw know that the Global event number can be programmed into INTA's >> unmapped event steering register. The DMA no longer have this register, >> it sends unmapped event to INTA. >> >> The unmapped event number is fixed per sources, they will arrive at the >> specific unmapped event configuration register of INTA. >> >> INTA itself does not know which source are allocated to be used by >> Linux, the allocation is for the DMA resources and only the DMA driver >> knows which channels, rings, flows can be used and can ask the INTA MSI >> domain to create interrupts for those. >> >> By handling the ti,unmapped-event-sources the INTA driver can make >> decision on the correct tisci dev_id to be used for the sysfw API to >> where the global event must be configured and the client drivers does >> not need to know how things are working under the hood. >> >> There are components in DMSS which use is exactly how they worked within >> NAVSS, they are not using unmapped events. Ringacc comes to mind first. >> >> I can add a comment block to explain the nature of unmapped events and >> the reason why we need to do what we do. >> >> Would this be acceptable? > > That'd be useful, as long as it is shorter than the above. OK, I will send an update next week after I'm back. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
