On 31/07/2019 23:41, Suman Anna wrote:

The PRUSS INTC receives a number of system input interrupt source events
and supports individual control configuration and hardware prioritization.
These input events can be mapped to some output interrupt lines through 2
levels of many-to-one mapping i.e. events to channel mapping and channels
to output interrupts.

This mapping information is provided through the PRU firmware that is
loaded onto a PRU core/s or through the device tree node of the PRU
application. The mapping is configured by the PRU remoteproc driver, and
is setup before the PRU core is started and cleaned up after the PRU core
is stopped. This event mapping configuration logic programs the Channel
Map Registers (CMRx) and Host-Interrupt Map Registers (HMRx) only when a
new program is being loaded/started and the same events and interrupt
channels are reset to zero when stopping a PRU.

Add two helper functions: pruss_intc_configure() & pruss_intc_unconfigure()
that the PRU remoteproc driver can use to configure the PRUSS INTC.

So let me see if I correctly understand this: this adds yet another
firmware description parser, with a private interface to another
(undisclosed?) driver, bypassing the standard irqchip configuration
mechanism. It sounds great, doesn't it?

What I cannot really infer from this message (-ETOOMUCHJARGON) is what
interrupts this affects:

- Interrupts from random devices to the PRUSS?
- Interrupts from the PRUSS to the host?
- Something else?

When does this happen? Under control of what? It isn't even clear why
this is part of this irqchip driver.

Depending what this does, there may be ways to fit it into the standard
interrupt configuration framework. After all, we already have standard
interfaces to route interrupts to virtual CPUs, effectively passing full
control of an interrupt to another entity. If you squint hard enough,
your PRUSS can fit that description.

If that doesn't work, then we need to make the IRQ framework grok that
kind of requirement (hence my request for clarification). But I'm
strongly opposed to inventing a SoC-private way of configuring
interrupts behind the kernel's back.

Thanks,

	M.
-- 
Jazz is not dead, it just smells funny...