On 11/27/18 9:39 AM, Roger Quadros wrote:
On 26/11/18 23:17, David Lechner wrote:
On 11/22/18 5:39 AM, Roger Quadros wrote:
From: Suman Anna <s-anna@xxxxxx>
The Programmable Real-Time Unit Subsystem (PRUSS) contains an
interrupt controller (INTC) that can handle various system input
events and post interrupts back to the device-level initiators.
The INTC can support upto 64 input events with individual control
configuration and hardware prioritization. These events are mapped
onto 10 interrupt signals through two levels of many-to-one mapping
support. Different interrupt signals are routed to the individual
PRU cores or to the host CPU.
The PRUSS INTC platform driver manages this PRUSS interrupt
controller and implements an irqchip driver to provide a Linux
standard way for the PRU client users to enable/disable/ack/
re-trigger a PRUSS system event. The system events to interrupt
channels and host interrupts relies on the mapping configuration
provided through a firmware resource table for now. This will be
revisited and enhanced in the future for a better interface. The
mappings will currently be programmed during the boot/shutdown
of the PRU.
Does this mapping table take up space in the PRU IRAM or DRAM? If
so, that can be a problem on the AM18xx because it has such limited
resources - every byte counts.
Currently the entire resource table is being placed in DRAM.
But that is only because the current rpmsg vdev implementation depends on the
rpmsg channel information and vring buffers to be in DRAM.
I think the right way is to split up the 2 things.
i.e. separate out rpmgs channel DRAM allocation from resource table
and don't copy the resource table to DRAM.
This way if there is no rpmsg channel in the resource table we won't eat
any DRAM.
I'm not sure if there are any bottlenecks. I will only know when I work on it.
Sounds good to me.
