Messages in this thread | | | Subject | Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts | From | David Lechner <> | Date | Wed, 28 Nov 2018 09:46:24 -0600 |
| |
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@ti.com> >>> >>> 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.
| |