linux-kernel - Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for PRUSS interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 28 Nov 2018 09:46:24 -0600
From:   David Lechner <david@...hnology.com>
To:     Roger Quadros <rogerq@...com>, tony@...mide.com
Cc:     robh+dt@...nel.org, bcousson@...libre.com, ssantosh@...nel.org,
        ohad@...ery.com, bjorn.andersson@...aro.org, s-anna@...com,
        nsekhar@...com, t-kristo@...com, nsaulnier@...com, jreeder@...com,
        m-karicheri2@...com, woods.technical@...il.com,
        linux-omap@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 08/17] soc: ti: pruss: Add a PRUSS irqchip driver for
 PRUSS interrupts

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@...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.