Re: [PATCH v4 1/5] dt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings

[Suman Anna <s-anna@ti.com>]

Hi David,

On 7/31/20 9:16 AM, Grzegorz Jaszczyk wrote:
> On Fri, 31 Jul 2020 at 16:09, David Lechner <david@lechnology.com> wrote:
>>
>> On 7/31/20 6:48 AM, Grzegorz Jaszczyk wrote:
>>> On Wed, 29 Jul 2020 at 19:34, David Lechner <david@lechnology.com> wrote:
>>>> It is not clear what the meaning of each cell is. Looking at later patches, it
>>>> looks like the first cell is the PRU system event number, the second cell is the
>>>> channel and the third cell is the host event number.
>>>
>>> Ok, how about updating above description like this:
>>> Client users shall use the PRU System event number (the interrupt source
>>> that the client is interested in) [cell 1], PRU channel [cell 2] and PRU
>>> host_intr (target) [cell 3] as the value of the interrupts property in their
>>> node.  The system events can be mapped to some output host interrupts through 2
>>> levels of many-to-one mapping i.e. events to channel mapping and channels to
>>> host interrupts so through this property entire mapping is provided.
>>
>> Cell 3 is host_intr0-7? How would we map to other host events?
> 
> Again this is due to misleading TRM nomenclature: host_intr vs host
> interrupts (one that we discuss in patch #2). I will use "and PRU host
> event (target) [cell 3]...". Sorry for my mistake.

Idea is to do the event mapping for other host interrupts using the 
irq_create_fwspec_mapping() function from the PRU remoteproc driver. We 
can't use DT to represent them, or atleast can't use "interrupts" 
property for them since they are not targeted towards the Linux host 
processor.

regards
Suman